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RECOMMENDATION G.709 
INTERFACE FOR THE OPTICAL TRANSPORT NETWORK (OTN) 



Summary 

This recommendation defines the requirements for the Optical Transport Module of order n (OTM- 
n) signals of the Optical Transport Network, in terms of: 

- Optical Transport Hierarchy (OTH); 

- functionality of the overhead in support of multi-wavelength optical networks; 

- frame structures; 

- bit rates; 

- formats for mapping client signals. 
Source and history 

This Recommendation forms part of a suite of Recommendations covering the full functionality of 
an Optical Transport Network. This Recommendation follows the principles defined in 
Recommendation G.805. 



Document history 


Issue 


Notes 


^ 2.0 Editor 


October 2001 - Added to this version are Backward 1AE, ODUk multiplexing and 




ODUk virtual concatenation. Subclause 7.4 and clauses IS and 19 are new. 


Appendices III, IV and V are new also. Other additions are presented with diff 


marks. 
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Initial version, February 2001 



Keywords 
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1 Scope 

The Optical Transport Hierarchy (OTH) supports the operation and management aspects of optical 
networks of various architectures e.g. point-to-point, ring and mesh architectures. 
This Recommendation defines the interfaces of the Optical Transport Network to be used within 
and between subnetworks of the optical network, in terms of: 

- Optical Transport Hierarchy (OTH); 

- functionality of the overhead in support of multi-wavelength optical networks; 

- frame structures; 

- bit rates; 

- formats for mapping client signals. 

The interfaces defined in this recommendation can be applied at User to Network Interfaces (UNI) 
and Network Node Interfaces (NNI) of the Optical Transport Network. It is recognised for 
interfaces used within optical subnetworks, aspects of the interface are optical technology 
dependent and subject to change as technology progresses. Therefore, optical technology dependent 
aspects (for transverse compatibility) are not defined for these interfaces to allow for technology 
changes. The overhead functionality necessary for operations and management of optical 
subnetworks is defined. 



2 References 

The following ITU-T Recommendations, and other references contain provisions, which, through 
reference in this text, constitute provisions of this Recommendation. At the time of publication, the 
editions indicated were valid. All Recommendations and other references are subject to revision; all 
users of this Recommendation are therefore encouraged to investigate the possibility of applying the 
most recent edition of the Recommendations and other references listed below. A list of the 
currently valid ITU-T Recommendations is regularly published. 

ITU-T G.652 - Characteristics of a single-mode optical fibre cable 

ITU-T G.653 - Characteristics of a dispersion-shifted single-mode optical fibre cable 

ITU-T G.655 - Characteristics of a non-zero dispersion shifted single-mode optical fibre 

cable 

ITU-T G.707 - Network Node Interface for the Synchronous Digital Hierarchy. 

ITU-T G.805 - Generic Functional Architecture of Transport Networks. 

ITU-T G.872 - Architecture of Optical Transport Networks. 

ITU-T G.959. 1 - Optical Transport Network Physical Layer Interfaces. 

ITU-T G.7042 - Link Capacity Adjustment Scheme (LCAS) For Virt ual Concatenation. 

ITU-T 1.432.1 - B-ISDN user-network interface - Physical layer specification: General 

ITU-T M.1400 - Designations for inter-operator networks 

ITU-T M.3 1 00 Amendment 3 - Definition of The Management Interface for a Generic 
Alarm Reporting Control (ARC) Feature 

ITU-T 0. 1 50 - General requirements for instrumentation for performance measurements on 
digital transmission equipment. 
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3 Terms and definitions 

This Recommendation uses terms defined in Recommendation G.707: 

3.1 BIP-X 

3 .2 Network node interface 

This Recommendation uses terms defined in Recommendation G.805: 

3.3 Adapted information (AI) 

3.4 Characteristic information (CI) 

3.5 Network, 

3.6 Subnetwork 

This Recommendation uses terms defined in Recommendation G.872: 

3.7 Intra Domain Interface (IaDI) 

3.8 Inter Domain Interface (IrDI) 

3.9 Optical transport network (OTN) 

3.10 Optical Multiplex Section (OMS) 

3.11 Optical Transmission Section (OTS) 
This Recommendation defines the following terms: 

3.12 Optical transport module (OTM-n|r].m): The OTM is the information structure that is 
transported across an ONNI. The index n and m define the number of supported wavelengths and 
bit rates at the interface as defined below. Two OTM structures are defined: 

3.12.1 OTM with full functionality (OTM-n.m) The OTM-n.m consists of up to n multiplexed 
optical channels and an OTM overhead signal to support the non-associated overhead. 

It is the information structure used to support optical transmission section (OTS) layer connections 
in the OTN. The characteristic information of the optical transmission section layer (OTS_CI) 
consists of information payload (OTS_CI_PLD) and optical transmission section overhead 
information fields (OTS_CI_OH). The optical transmission section overhead (OTS OH) 
information fields are contained within the OTM overhead signal (OOS) information structure. The 
order of an OTM-n is defined by the order of the OMU-n that it supports. 

3 .12.2 OTM with reduced functionality (OTM-O.m, OTM-nr.m): The OTM-0 consists of a 
single optical channel without a specific color assigned. The OTM-nr.m consists of up to n 
multiplexed optical channels. Non associated overhead is not supported. 

The OTM-nr.m/OTM-0 is the information structure used to support optical physical section (OPS) 
layer connections in the OTN. The characteristic information of the optical physical section layer 
(OPS_CI) consists of information payload (OPS_CI_PLD). Non-associated overhead is not 
supported. The order of an OTM-nr is defined by the order of the OCG-nr that it supports. 

Note that for the first version of G.709, the standardized IrDI interfaces are all reduced functionality 
interfaces. OTM-0 and OTM- 1 6r are defined. 

3.13 n: The index "n" is used to represent the order of the OTM, OTS, OMS, OPS, OCG, OMU. 
n represents the maximum number of wavelengths that can be supported at the lowest bit rate 
supported on the wavelength. It is possible that a reduced number of higher bit rate wavelengths are 
supported. n=0 represents the case of a single channel without a specific color assigned to the 
channel. 
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3.14 r. The index "r", if present, is used to indicate a reduced functionality OTM, OCG, OCC 
and OCh (non-associated overhead is not supported). Note that for n=0 the index r is not required as 
it implies always reduced functionality. 

3.15 m: The index "m" is used to represent the bit rate or set of bit rates supported on the 
interface. This is one or more digits "k" where each "k" represents a particular bit rate. The valid 
values for m are (1, 2, 3, 12, 123, 23). 

3.16 k: The index "k" is used to represent a supported bit rate and the different versions of 
OPUk, ODUk and OTUk. k=l represents an approximate bit rate of 2.5 Gbit/s, k=2 represents an 
approximate bit rate of 10 Gbit/s, and k=3 represents an approximate bit rate of 40 Gbit/s. 

3.17 Optical channel (OCh[r]): The OCh is the information structure used to support the OCh 
trail. Two OCh structures are defined. 

The OCh client signals defined in this recommendation are the OTUk signals. Other digital client 
signals (e.g. STM-N, GbE) may be supported by the OTM. 

NOTE - Further characterisation of the OCh may be required to differentiate one OCh signal (e.g. 
one carrying an OTU1) from another OCh signal (e.g. one carrying an OTU2 or GbE). This is for 
further study. 

3.17.1 Optical channel with full functionality (OCh): The OCh is an information structure 
consisting of the information payload (OCh-PLD) with a certain bandwidth and non-associated 
overhead (OCh-OH) for management of the optical channel. 

3.17.2 Optical channel with reduced functionality (OChr): The OChr is an information 
structure consisting of the information payload (OCh-PLD) with a certain bandwidth. Non- 
associated overhead is not supported. 

3.18 Optical channel transport unit (OTUkfV]): The OTUk is the information structure used 
for transport of an ODUk over one or more optical channel connections. It consists of the optical 
channel data unit and OTUk related overhead (FEC and overhead for management of an optical 
channel connection). It is characterized by its frame structure, bit rate, and bandwidth. OTUk 
capacities for k=l , k=2, k=3 are defined. 

Two versions of the OTUk are defined: 

3.18.1 Completely standardised OTUk (OTUk): The completely standardised OTUk is used on 
OTM IrDIs and may be used on OTM IaDIs. 

3.18.2 Functionally standardised OTUk (OTUkV): The partly standardised OTUk is used on 
OTM IaDIs. 

3.19 Optical channel data unit (ODUk): The ODUk is an information structure consisting of 
the information payload (OPUk) and ODUk related overhead. ODUk capacities for k=l, k=2, k=3 
are defined. 

3.19.1 ODUk Path (ODUkP): The optical channel data unit k path (ODUkP) is the information 
structure used to support the end-to-end ODUk trail. 

3.19.2 ODUk TCM (ODUkT): The optical channel data unit k TCM (ODUkT) is the information 
structure used to support the TCM trails. Up to 6 TCM sub-layers are supported. 

3.20 Optical channel payload unit (OPUk): The OPUk is the information structure used to 
adapt client information for transport over an optical channel. It comprises client information 
together with any overhead needed to perform rate adaptation between the client signal rate and the 
OPUk payload rate and other OPUk overhead supporting the client signal transport. This overhead 
is adaptation specific. OPUk capacities for k=l, k=2, k=3 are defined. 
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3.21 Optical Channel Carrier (OCC[r]): The optical channel carrier represents a tributary slot 
within the OTM-n. Two OCC structures are defined: 

NOTE - Further characterisation of the OCC may be required to differentiate one OCC tributary slot 
(e.g. one able to carry an OTU1) from another OCC tributary slot (e.g. one able to carry an OTU3). 
This is for further study. 

3.2 1 . 1 OCC with full functionality (OCC): The OCC consists of the OCC Payload (OCCp) and 
OCC Overhead (OCCo). The OCCp carries the OCh_CI_PLD and is assigned to a 
wavelength/frequency slot of the WDM group. The OCCo carries the OCh_CI_OH and is 
transported within the OOS information structure. 

3.21.2 OCC with reduced functionality (OCCr): The OCC consists of the OCC Payload 
(OCCp). The OCCp carries the OCh_CI_PLD and is assigned to a wavelength/frequency slot of the 
WDM group. Non-associated overhead is not supported. 

3.22 Optical Carrier Group of order n (OCG-n[r]): n Optical Channel Carriers occupying 
fixed, defined positions in an OTM payload are termed an Optical Carrier Group (OCG[r]). Two 
OCG structures are defined: 

3.22. 1 OCG with full functionality (OCG-n) : The OCG-n consits of up to n OCC Payload 
(OCCp) and OCC Overhead (OCCo). 

3.22.2 OCG with reduced functinality (OCG-nr) : The OCG-nr consits of up to n OCC Payload 
(OCCp). Non-associated overhead is not supported. 

3.23 Optical Multiplex Unit (OMU-n, i£l): The OMU-n is the information structure used to 
support optical multiplex section (OMS) layer connections in the OTN. The characteristic 
information of the optical multiplex section layer (OMS_CI) consists of information payload 
(OMS_CI_PLD) and optical multiplex section overhead information fields (OMS_CI_OH). The 
OMS_CI_PLD consists of the OCG-n payload. The OMS_CI_OH consists of the OCG-n overhead 
and OMS specific overhead and is transported within the OOS information structure. The order of 
the OMU is defined by the order of the OCG that it supports. 

3.24 Optical physical section of order n (OPSn): A layer network that provides functionality 
for transmission of a multi-wavelength optical signal on optical media of various types (e.g. G.652, 
G.653 and G.655 fibre). Note that a "multi-wavelength" signal includes the case of just one optical 
channel. 

It combines the transport functionality of the OMS and OTS layer networks without their 
supervisory information. OPSn capacities for n=0 and n=16 are defined. 

3.25 Optical transport network node interface (ONNI): The interface at an optical transport 
network node which is used to interconnect with another optical transport network node. 

3.26 OTM Overhead Signal (OOS): The OOS is the information structure used for transport of 
OTM non-associated overhead over the optical supervisory channel. The non-associated overhead 
consists of the optical transmission section overhead, optical multiplex section overhead and optical 
channel non-associated overhead. It is characterized by its frame structure, bit rate, and bandwidth. 

3.27 Optical supervisory channel (OSC): The physical carrier outside of the amplifier band 
that provides transport of the OTM Overhead Signal. 

3.28 Optical transport hierarchy (OTH): The OTH is a hierarchical set of digital transport 
structures, standardized for the transport of suitably adapted payloads over optical transmission 
networks. 

3.29 OTH multiplexing : A procedure by which optical channels are multiplexed. 
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330 Non-associated overhead (naOH): Supervisory information transported in an OOS. 

3.3 1 Hitless activation/deactivation of a Connection Monitor applies to TC-CMEPs. It 
means that a CM between two TC-CMEPs can be established/released without impacting payload 
data, or any unrelated OH information. Therefore, unrelated management functions are also not 
impacted. More specifically, previously established CMs will not reflect transient error conditions 
or statistics as a direct result of the activation/deactivation of the new/old CM. 

3.32 CBR2G5 : A constant bit rate signal of 2 488 320 kbit/s ± 20 ppm. An example of such 
signal is a STM-16 signal. 

3.33 CBR10G: A constant bit rate signal of 9 953 280 kbit/s ± 20 ppm. An example of such 
signal is a STM-64 signal. 

3.34 CBR40G: A constant bit rate signal of 39 813 120 kbit/s ± 20 ppm. An example of such 
signal is a STM-256 signal. 

3.35 Connection Monitoring End Point (CMEP): Connection monitoring end-points represent 
end points of trails and correspond as such with the trail termination functions. Connection 
monitoring overhead (CMOH) is inserted and extracted at the CMEPs. 

For the OCh the CMEPs are categorized in three classes: 

OCh Optical Section CMEP (OS-CMEP), which represents the end-points of the OTUk 
trail. The SM overhead field (see Figure 15-9 and Figure 15-10) contains the related 
CMOH 

OCh Tandem Connection CMEP (TC-CMEP), which represents the end-points of ODUkT 
trails. The TCM1..6 overhead fields (see Figure 15-12 and Figure 15-13) contain the related 
CMOH. 

OCh Path CMEP (P-CMEP), which represents the end-points of the ODUkP trail. The PM 
overhead field (see Figure 15-12 and Figure 15-14) contains the related CMOH. 

3.36 Link Capacity- Adjustment Scheme (LCAS): LCAS in the virtual concatenation source 
and sink adaptation functions provides a control mechanism to hitlesslv increase or decrease the 
capacity of a link to meet the bandwidth needs of the application. It also p rovides a means of 
removing member links that have experienced failure. The LCAS assumes that in cases of capacity 
initiation, increases or decreases, the construction or destruction of the end-to-end path is the 
responsibility of the Network and Element Management Systems. 

4 Abbreviations 



This Recommendation uses the following abbreviations: 



OxYY 


YY is a value in hexadecimal presentation 


3R 


Reamplification, Reshaping and Retiming 


ACT 


Activation (in the TCM ACT byte) 


AI 


Adapted information 


AIS 


Alarm Indication Signal 


APS 


Automatic Protection Switching 


BDI 


Backward Defect Indication 


BDI-O 


Backward Defect Indication Overhead 
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BDI-P 


Backward Defect Indication Payload 


BEI 


Backward Error Indication 


BI 


Backward Indication 


B1AE 


Backward Jncomina Alignment Error 


BIP 


Bit Interleaved Parity 


CBR 


Constant Bit Rate 




Characteristic information 


CM 


i^oiineciion ivioniionng 


CMEP 


Connection Monitoring End Point 


CMOH 


Connection Monitoring overhead 


CRC 


Cyclic Redundancy Check 


V- 1 TV I— 


Cnntml wnrH ^pnt from source to sink 

V^VjJllIvl Wvl.U OtllL XI will JVUIVW lv 


DAPI 


Destination Access Point Identifier 


DNU 


Do Not Use 


EDC 


Error Detection Code 


EOS 


End of Sequence 


EXP 


Experimental 


ExTI 


Expected Trace Identifier 


FAS 


Frame Alignment Signal 


FDI 


Forward Defect Indication 


rui-vj 


T*nr\\rckrA T*if*€f*r , t TnHicatirvn OvprhpaH 
rorvVolu L/ClCLl llluiwaiivJii wvcincau 


FDI-P 


Forward Defect Indication Payload 


FEC 


Forward error correction 


GCC 


General Communication Channel 


Gin 


Ornun Identification 


TaT"YT 

laui 


imra-i-Joniain liiiciiacc 


IAE 


Incoming Alignment Error 


IrDI 


Inter-Domain Interface 


JOH 


Justification Overhead 


LCAS 


Link Capacity Adjustment Scheme 


LSB 


Least Significant Bit 


MFAS 


MultiFrame Alignment Signal 


MFI 


Multiframe Indicator 


MS 


Maintenance Signal 


MSB 


Most Significant Bit 
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MSI 


Multiplex Structure Identifier 


M QT 
Mb 1 


ivieniDei oiauib 


naUH 


non-associated overhead 


XTXTT 


rserworK noae lnieridcc 


NORM 


Normal uperaung ivioue 


occ 


^t\4</>nt Pltnnnal PoiTipr 

upticai cnannei earner 


OCCO 


uptical cnannei earner - overncdu 


OCCp 


Optical Channel earner - payioaa 


OCCr 


Uptical L/nannei Lamer wiin reuueeu iiuK/uuiiauiy 


OCG 


Optical Carrier Group 


OCGr 


Optical Carrier Group with reduced functionality 


OCI 


Open Connection Indication 


OCh 


Optical cnannei witn run iunctionaiuy 


OChr 


Uptical cnannei witn reauceu iiuicit>iidiiiy 


ODTUik 


Optical channel Data Tributary 7 Unit i into k 


ODl UCr 


Uotical cnannei Data liiDuiarv unu vjiuup 


UDU 


Uptical cnannei Data unit 


/""\T"\T T1 _ 

ODUk 


Uptical Cnannei Data unit-K 


ODUk-AV 


A virtually concatenated uuuk j> 


OH 


Overhead 


OMS 


Optical multiplex section 


UMo-Url 


upticai multiplex section ovciiicdu 


UMU 


Uptical Multiplex unit 


UJNJN1 


Upticai networK noae interlace 


oos 


OTM Overhead Signal 


Uro 


upticai r nysicdi occuun 




fYntipnl fViannpl Pavlnad Unit 


UrUK 


Or%tir»ol P'Viannpl PnvlnaH I Ttlit-k" 
wpilCal l^ndlllici rdyiudu vjiiil iv 


OPT fV-Yv 


Y virtual! v rnncntenated OPUk's 


AQA 

UoC 


Or\tir , c*l Qnnprvi enrv f^tiannpl 


OTH 


Optical transport hierarchy 


OTM 


Optical transport module 


OTN 


Optical transport network 


OTS 


Optical transmission section 


OTS-OH 


Optical transmission section overhead 
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OTU Optical Channel Transport Unit 

OTUk completely standardised Optical Channel Transport Unit-k 

OTUkV functionally standardised Optical Channel Transport Unit-k 

PCC Protection Communication Channel 

PLD Payload 

PM Path Monitoring 

PMI Payload Missing Indication 

PMOH Path Monitoring OverHead 

ppm parts per million 

PRBS Pseudo Random Binary Sequence 

PSI Payload Structure Identifier 

PT Payload Type 

RES Reserved for future international standardisation 

RS Reed-Solomon 

RS-Ack Re-sequence acknowledge 

SAPI Source Access Point Ideiiifier 

Sk Sink 

SM Section Monitoring 

SMOH Section Monitoring OverHead 

So Source 

SO Sequence Indicator 

TC Tandem Connection 

TCM Tandem Connection Monitoring 

TCMOH Tandem Connection Monitoring OverHead 

TS Tributary Slot 

TxTI Transmitted Trace Identifier 

UNI User to Network Interface 

VCG Virtual Concatenation Group 

VCOH Virtual Concatenation Overhead 

vcPT virtual concatenated Payload Type 



5 Conventions 



The functional architecture of the Optical Transport Network as specified in ITU-T 
Recommendation G.872 is used to derive the ONNI. The ONNI is specified in terms of the adapted 
and characteristic information present in each layer as described in ITU-T Recommendation G.805. 
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Transmission Order The order of transmission of information in all the diagrams in this 
Recommendation is first from left to right and then from top to bottom. Within each byte the most 
significant bit is transmitted first. The most significant bit (bit 1) is illustrated at the left in all the 
diagrams. 

Value of Reserved bit(s): The value of an overhead bit, which is Reserved or Reserved for future 
international standardisation shall be set to "0". 

Value of non-sourced bit(s): Unless stated otherwise, any non-sourced bits shall be set to "0". 

OTUk, ODUk and OPUk overhead assignment : The assignment of overhead in the optical 
channel transport/data/payload unit signal to each part is defined in Figure 5-1. 
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FIGURE 5-1/G.709 
OTUk, ODUk and OPUk Overhead 



6 Optical transport network interface structure 

The Optical Transport Network as specified in ITU-T Recommendation G.872 defines two interface 
classes: 

Inter-Domain Interface (IrDI); 
• Intra-Domain Interface (IaDI). 

The OTN IrDI interfaces are defined with 3R processing at each end of the interface. 



The Optical Transport Module-n (OTM-n) is the information structure used to support OTN 
interfaces. Two OTM-n structures are defined: 

OTM interfaces with full functionality (OTM-n.m); 

OTM interfaces with reduced functionality (OTM-O.m, OTM-nr.m). 

The reduced functionality OTM interfaces are defined with 3R processing at each end of the 
interface to support the OTN IrDI interface class. 
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6.1 Basic signal structure 

The basic structure is shown in Figure 6-1. 

6.1.1 OCh substructure 

The Optical Channel layer as defined in G.872 is further structured in layer networks in order to 
support the network management and supervision functionalities defined in G.872: 

The Optical Channel with full (OCh) or reduced functionality (OChr), which provides 
transparent network connections between 3R regeneration points in the OTN. 
The completely or functionally standardised Optical Channel Transport Unit 
(OTUk/OTUkV) which provides supervision and conditions the signal for transport 
between 3R regeneration points in the OTN. 
The Optical Channel Data Unit (ODUk) which provides 

- tandem connection monitoring (ODUkT), 

- end-to-end path supervision (ODUkP) and 

- adaptation of client signals via the Optical Channel Payload Unit (OPUk). 

6.1.2 Full functionality OTM-n.m (i£ 1) structure 

The OTM-n.m (i£l) consists of the following layers: 
• Optical Transmission Section (OTSn) 

Optical Multiplex Section (OMSn) 

Full functionality Optical Channel (OCh) 

Completely or functionally standardised Optical Channel Transport Unit (OTUk/OTUkV) 
Optical Channel Data Unit (ODUk). 

6.1.3 Reduced functionality OTM-nr.m and OTM-O.m structure 

The OTM-nr.m and OTM-O.m consists of the following layers: 
Optical Physical Section (OPSn) 
Reduced functionality Optical Channel (OChr) 

Completely or functionally standardised Optical Channel Transport Unit (OTUk/OTUkV) 
Optical Channel Data Unit (ODUk). 
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Clients (e.g. STM-N, ATM, IP, Ethernet) 













j OPUk j 
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substructure 
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i 
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OMSn 




OPSn 
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OTM 


l-n.m 




OTM-O.m 


i, OTM-nr.m 



Full functionality Reduced functionality 

OTM interface OTM interface 

FIGURE 6- 1/G.709 
Structure of the OTN Interfaces 

6.2 Information structure for the OTN interfaces 

The information structure for the OTN interfaces is represented by information containment 
relationships and flows. The principal information containment relationships are described m Frgure 
6-2, Figure 6-3 and Figure 6-4. The information flows are illustrated in Figure 6-5. 
For supervision purposes in the OTN, the OTUk/OTUkV signal is terminated whenever the OCh 
signal is terminated. 
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NOTE - The model in this figure is for illustrative purposes only. X represents an optical wavelength. 

FIGURE 6-5/G.709 

Example of information flow relationship 



7 Multiplexing/Mapping Principles and Bit Rates 

Figure 7-1 shows the relationship between various information structure elements and illustrates the 
multiplexing structure (including wavelength and time division multiplexing) and mappings for the 
OTM-n. 

The OTS, QMS, OCh and COMMS overhead is inserted into the OOS using mapping and 
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multiplexing techniques outside the scope of this recommendation. 



7.1 Mapping 

The client signal or an Optical channel Data unit "Tributary Unit Group (ODTUGk) is mapped into 
the OPUk. The OPUk is mapped into an ODUk and the ODUk is mapped into an OTUk[V]. The 
OTUk[V] is mapped into an OCh[r] and the OCh[r] is then modulated onto an OCC[r]. 

7.2 Wavelength Division Multiplex 

Up to n (i£l) OCC[r] are multiplexed into an OCG-n[r].m using wavelength division multiplexing. 
The OCC[r] tributary slots of the OCG-n[r].m can be of different size. 

The OCG-n[r].m is transported via the OTM-n[r].m. For the case of the full functionality OTM-n.m 
interfaces the OSC is multiplexed into the OTM-n.m using wavelength division multiplexing. 
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7.3 Bit rates and capacity 

The bit rates and capacity of the OTUk signals are defined in Table 7-1 . 

The bit rates and capacity of the ODUk signals are defined in Table 7-2. 

The bit rates and capacity of the OPUk and OPUk-Xv Payload are defined in Table 7-3. 

The OTUk/ODUk/OPUk /OPUk-Xv frame periods are defined in Table 7-4. 



TABLE 7-1/G.709 
OTU types and capacity 



OTU type 


OTU nominal bit rate 


OTU bit rate tolerance 


OTU1 


255/238 * 2 488 320 kbit/s 


± 20 ppm 


OTU2 


255/237 * 9 953 280 kbit/s 


OTU3 


255/236 * 39 813 120 kbit/s 


NOTE - The nominal OTUk rates are approximately: 2 666 057.143 kbit/s (OTU1), 
10 709 225.316 kbit/s (OTU2) and 43 018 413.559 kbit/s (OTU3). 



TABLE 7-2/G.709 
ODU types and capacity 



ODUtype 


ODU nominal bit rate 


ODU bit rate tolerance 


ODU1 


239/238 * 2 488 320 kbit/s 


±20 ppm 


ODU2 


239/237 * 9 953 280 kbit/s 


ODU3 


239/236*39 813 120 kbit/s 


NOTE - The nominal ODUk rates are approximately: 2 498 775.126 kbit/s (ODU1), 
10 037 273.924 kbit/s (ODU2) and 40 319 218.983 kbit/s (ODU3). 



TABLE 7-3/G.709 
OPU types and capacity 



OPUtype 


OPU Payload nominal bit rate 


OPU Payload bit rate tolerance 


OPU1 


2 488 320 kbit/s 


±20 ppm 


OPU2 


238/237 * 9 953 280 kbit/s 


OPU3 


238/236 * 39 813 120 kbit/s 


OPUl-Xv 


X * 2 488 320 kbit/s 


± 20 ppm 


OPU2-Xv 


X * 238/237 * 9 953 280 kbit/s 


OPU3-Xv 


X* 238/236 * 39 813 120 kbit/s 




NOTE - The nomii 
(OPU1 Payload), 9 
(OPU3 Payload). 


lal OPUk Payload rates are approximately: 2 488 320.000 kbit/s 
995 276.962 kbit/s (OPU2 Payload) and 40 150 519.322 kbit/s 
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TABLE 7-4/G.709 
OTUk/ODUk/OPUk frame periods 



OTU/ODU/OPU type 


Period (note) 


OTU1/ODU1/OPU1/OPU1 -Xv 


48.971 ps 


OTU2/ODU2/OPU2'OPU2-Xv 


12.191 ps 


OTU3/ODU3/OPU3/OPU3-Xv 


3.035 ps 


NOTE - The period is an approximated value, rounded to 3 digits. 



7.4 ODUk Time Division Multiplex 

Figure 7-1 shows the relationship between various time division multiplexing elements that are 
defined below, and illustrates possible multiplexing structures. Up to 4 ODU1 signals are 
multiplexed into an ODTUG2 using time division multiplexing. The ODTUG2 is mapped into the 
OPU2. A mixture of j (j < 4) ODU2 and 16-4j ODU1 signals can be multiplexed into an ODTUG3 
using time division multiplexing. The ODTUG3 is mapped into the OPU3. 
Figures 7-2 and 7-3 show how various signals are multiplexed using these multiplexing elements. 
Figure 7-2 presents the multiplexing of four ODU1 signals into the OPU2 signal. An ODU1 signal 
is extended with frame alignment overhead and asynchronously mapped into the Optical channel 
Data Tributary Unit 1 into 2 (ODTU12) using the justification overhead (JOH). The four ODTU12 
signal are time division multiplexed into the Optical channel Data unit Tributary Unit Group 2 
(ODTUG2), after which this signal is mapped into the OPU2. 

Figure 7-3 presents the multiplexing of up to 16 ODU1 signals and/or up to 4 ODU2 signals into 
the OPU3 signal. An ODU1 signal is extended with frame alignment overhead and asynchronously 
mapped into the Optical channel Data Tributary Unit 1 into 3 (ODTU13) using the justification 
overhead (JOH). An ODU2 signal is extended with frame alignment overhead and asynchronously 
mapped into the Optical channel Data Tributary Unit 2 into 3 (ODTU23) using the justification 
overhead (JOH). "x" ODTU23 (0 < x < 4) signals and "16-4x" ODTU13 signals are time division 
multiplexed into the Optical channel Data unit Tributary Unit Group 3 (ODTUG3), after which this 
signal is mapped into the OPU3. 

Details of the multiplexing method and mappings are given in clause 19. 

An example illustrating the multiplexing of 4 ODU1 signals into an ODU2 is presented in 

Appendix III. 
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FIGURE 7-2/G.709 
ODU1 into ODU2 multiplexing method 
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FIGURE 7-3/G.709 
ODU1 and ODU2 into ODU3 multiplexing method 
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8 Optical transport module (OTM-n.m, OTM-nr.m, OTM-O.m) 

Two OTM structures are defined, one with full functionality and one with reduced functionality. 
For the IrDI only reduced functionality OTM interfaces are currently defined. Other fall or reduced 
functionality OTM IrDIs are for further study. 

8.1 OTM with reduced functionality (OTM-O.m, OTM-nr.m) 

The OTM-n supports n optical channels on a single optical span with 3R regeneration and 
termination of the OTUk[V] on each end. As 3R regeneration is performed on both sides of the 
OTM-O.m and OTM-nr.m interfaces access to OTUk[V] overhead is available and 
maintenance/supervision of the interface is provided via this overhead. Therefore non-associated 
OTN overhead is not required across the OTM-O.m and OTM-nr.m interfaces and an OSC/OOS is 
not supported. 

Two OTM interfaces classes with reduced functionality are defined, OTM-O.m and OTM-16r.m. 
Other reduced functionality interfaces classes are for farther study. 

8.1.1 OTM-O.m 

The OTM-O.m supports a non-coloured optical channel on a single optical span with 3R 
regeneration at each end. 

Three OTM-O.m interface signals (Figure 8-1 ) are defined, each carrying a single channel optical 
signal containing one OTUk[V] signal: 

OTM-0.1 (carrying an OTUl[V]); 

OTM-0.2 (carrying an OTU2[V]); 

OTM-0.3 (carrying an OTU3[V]). 
In generic terms: OTM-O.m. 

Figure 8-1 shows the relationship between various information structure elements that are defined 
below and illustrates possible mappings for the OTMO.m. 

An OSC is not present and there is no OOS either. 
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FIGURE 8-1/G.709 
OTM-O.m structure 
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8.1.2 OTM-16r.m 

This 0TM-16r.m supports 16 optical channels on a single optical span with 3R regeneration at each 
end. 

Six OTM-16r interface signals are defined: 

OTM-16r.l (carrying i (i < 16) OTU1 [V] signals); 
OTM-16r.2 (carrying j (j < 16) OTU2[V] signals); 
OTM-16r.3. (carrying k (k < 16) OTU3[V] signals); 

OTM-16r.l23 (carrying i (i < 16) OTUl[V], j (j < 16) OTU2[V] and k (k < 16) OTU3[V] 
signals with i + j + k < 16); 

OTM-16r.l2 (carrying i (i < 16) OTUl[V] and j (j < 16) OTU2[V] signals with i + j < 16) 
OTM-16r.23 (carrying j (j < 16) OTU2[V] and k (k < 16) OTU3[V] signals with j + k < 
16). 

in generic terms identified as OTM-16r.m. 

The OTM-16r.m signal is an OTM-nr.m signal with 16 Optical Channel Carriers (OCCr) numbered 
OCCr #0 to OCCr #15 (Figure 6-5). An Optical Supervisory Channel (OSC) is not present and there 
is no OOS either. 

At least one of the OCCrs is in service during normal operation and transporting an OTUk[V]. 
There is no predefined order in which the OCCrs are taken into service. 

The six defined OTM-16r.m interface signals and the OTM-16r.m multiplexing structure is shown 
in Figure 8-2. 

NOTE - OTM-16r.m OPS overhead is not defined. The interface will use the OTUk[V] SMOH in 
this multiwavelength interface for supervision and management. OTM-16r.m connectivity (TIM) 
failure reports will be computed from the individual OTUk[V] reports by means of failure 
correlation in fault management. Refer to the equipment recommendations for further details. 
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FIGURE 8-2/G.709 
OTM-16r.m multiplexing structure 



8.2 OTM with full functionality (OTM-n.m) 

The OTM-n.m interface supports up to n optical channels for single or multiple optical spans. 3R 
regeneration is not required at the interface. 
Six OTM-n interface signals are defined: 

- OTM-n. 1 (carrying i (i < n) OTU1 [V] signals) 
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- OTM-n.2 (carrying j (j < n) 0TU2[V] signals) 

- OTM-n.3. (carrying k (k < n) 0TU3[V] signals) 

- OTM-n. 123 (carrying i (i < n) OTU1 [V], j (j < n) OTU2[V] and k (k < n) OTU3[V] 
signals with i + j + k < n) 

- OTM-n. 12 (carrying i (i < n) OTU1 [V] and j (j < n) OTU2[V] signals with i + j < 
n) 

- OTM-n.23 (carrying j 0 ^ n) OTU2[V] and k (k < n) OTU3[V] signals with j + k < 
n) 

in generic terms identified as OTM-n.m. 

An OTM-n.m interface signal contains up to "n" OCC's associated with the lowest bit rate that is 
supported as indicated by m and an OSC (Figure 8-3). It is possible that a reduced number of higher 
bit rate capable OCCs are supported. The value of "n", "m" and the OSC are not defined in this 
Recommendation. 
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FIGURE 8-3/G.709 
OTM-n.m multiplexing structure 
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9 Physical specification of the ONNI 

9.1 OTM-O.m 

Specifications for physical optical characteristics of the OTM-0.1 and OTM-0.2 signals are 
contained in Recommendation G.959. 1 . 

Specifications for physical optical characteristics of the OTM-0.3 are for further study. 

9.2 OTM-16r.m 

Specifications for physical optical characteristics of the OTM-16r.l and OTM-16r.2 signals are 
contained in Recommendation G.959. 1 . 

Specifications for physical optical characteristics of the OTM-16r.3, OTM-16r.l2, OTM-16r.23 and 
OTM- 1 6r. 1 23 are for further study. 

9.3 OTM-n.m 

Specifications for physical optical characteristics of the OTM-n.m are vendor specific and outside 
the scope of this Recommendation. 



10 Optical channel (OCh) 

The OCh transports a digital client signal between 3R regeneration points. The OCh client signals 
defined in this recommendation are the OTUk signals. Other digital client signals (e.g. STM-N, 
GbE) may be supported by the OTM. 



10.1 OCh with full functionality (OCh) 

The optical channel with full functionality (OCh) structure is conceptually shown in Figure 10-1. It 
contains two parts: OCh Overhead and OCh Payload. 
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FIGURE 10-1/G.709 
OCh information structure 

10.2 OCh with reduced functionality (OChr) 

The optical channel with reduced functionality (OChr) structure is conceptually shown in Figure 
10.2. It contains: OChr Payload. 
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OChr Payload 



FIGURE 10-2/G.709 
OChr information structure 



1 1 Optical channel transport unit (OTU) 

The OTUkfVl conditions the ODUk for transport over an Optical Channel network connection. The 
OTUk frame structure is completely standardised. The OTUkV is a frame structure that is only 
functionally standardised (i.e., only the required functionality is specified); refer to Appendix II. 

11.1 OTUk frame structure 

The OTUk (k=U,3) frame structure is based on the ODUk frame s ^ cme ™ d f* e f s j^^* 
forward error correction (FEC) as shown in Figure 11-1. 256 columns are added to the ODUk frame 
for the FEC and the reserved overhead bytes in row 1, columns 8 to 14 of the ODUk overhead are 
used for OTUk specific overhead, resulting in an octet based block frame structure with 4 rows and 
4080 columns. The MSB in each octet is bit 1 , the LSB is bit 8. 
The bit rates of the OTUk signals are defined in Table 7-1 . 
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FIGURE 1M/G.709 
OTUk frame structure 



The OTUk Forward Error Correction (FEC) contains the Reed-Solomon RS(255,239) FEC codes. If 
no FEC is used, fixed stuff bytes (all-O's pattern) are to be used. 

The RS(255,239) FEC code shall be computed as specified in Annex A/G.709. 

For interworking of equipment supporting FEC, with equipment not supporting FEC (inserting 
fixed stuff all-O's pattern in the OTUk FEC area), the FEC supporting equipment shall support the 
capability to disable the FEC decoding process (ignore the content of the OTUk FEC). 

The transmission order of the bits in the OTUk frame is left to right, top to bottom, and MSB to 
LSB (Figure 11-2). 
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FIGURE 11-2/G.709 
Transmission order of the OTUk frame bits 
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; + x 3 + x 12 + x 16 . Figure 1 1-3 shows a functional diagram 



11.2 Scrambling 

The OTUk signal must have sufficient bit timing content at the ONNI. A suitable bit partem, which 
prevents a long sequence of " l"s or "0"s, is provided by using a scrambler. 
The operation of the scrambler shall be functionally identical to that of a frame synchronous 
scrambler of sequence length 65535 operating at the OTUk rate. 

The generating polynomial shall be 1 + x + x 3 + x 12 ' J 
of the frame synchronous scrambler. 

The scrambler shall be reset to "FFFF" (HEX) on the most significant bit of the byte following the 
last framing byte in the OTUk frame, i.e. the MSB of the MFAS byte This bit, and all subsequent 
bits to be scrambled, shall be added modulo 2 to the output from the x ! 6 position of the scrambler. 
The scrambler shall run continuously throughout the complete OTUk frame. The framing bytes 
(FAS) of the OTUk overhead shall not be scrambled. 

Scrambling is performed after FEC computation and insertion into the OTUk signal. 
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FIGURE 11-3/G.709 
Frame synchronous scrambler 



12 Optical channel data unit (ODUk) 
12.1 ODUk frame structure 

The ODUk (k=l,2,3) frame structure is shown in Figure 12-1. It is organized in an octet based 
block frame structure with 4 rows and 3824 columns. 
The two main areas of the ODUk frame are: 

ODUk Overhead area; 

OPUk area. 

Columns 1 to 14 of the ODUk are dedicated to ODUk Overhead area. 

NOTE - Columns 1 to 14 of row 1 are reserved for Frame Alignment and OTUk specific Overhead. 
Columns 15 to 3824 of the ODUk are dedicated to OPUk area. 
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FIGURE 12- l/G/709 
ODUk frame structure 



13 Optical channel payload unit (OPUk) 

The OPUk (k= 1,2,3) frame structure is shown in Figure 13-1. It is organized in an octet based block 
frame structure with .4 rows and 3810 columns. 

The two main areas of the OPUk frame are: 
OPUk Overhead area; 
OPUk Payload area. 

Columns 15 to 16 of the OPUk are dedicated to OPUk Overhead area. 

Columns 17 to 3824 of the OPUk are dedicated to OPUk Payload area. 

NOTE - OPUk column numbers are derived from the OPUk columns in the ODUk frame. 
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FIGURE 13-1/G.709 
OPUk frame structure 
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14 OTM overhead signal (OOS) 

The OTM Overhead Signal (OOS) consists of the OTS, OMS and OCh overhead. The format, 
structure and bit rate of the OOS is not defined in this Recommendation. The OOS is transported 
via an OSC. 

Depending on an operator's logical management overlay network design, general management 
communications may also be transported within the OOS. Therefore, the OOS for some 
applications may also transport general management communications. General management 
communications may include signalling, voice/voiceband communications, software download, 
operator specific communications, etc. 

15 Overhead description 

An overview of OTS, OMS and OCh overhead is presented in Figure 15-1. 

An overview of OTUk, ODUk and OPUk overhead is presented in Figure 15-2 and Figure 15-3. 

1 5.1 Types of overhead 

15.1.1 Optical Channel Payload Unit Overhead (OPUk OH) 

OPUk OH information is added to the OPUk information payload to create an OPUk. It includes 
information to support the adaptation of client signals. The OPUk OH is terminated where the 
OPUk is assembled and disassembled. The specific OH format and coding is defined in 15.9. 

15.1.2 Optical Channel Data Unit Overhead (ODUk OH) 

ODUk OH information is added to the ODUk information payload to create an ODUk. It includes 
information for maintenance and operational functions to support optical channels. The ODUk OH 
consists of portions dedicated to the end-to-end ODUk path and to six levels of tandem connection 
monitoring. The ODUk path OH is terminated where the ODUk is assembled and disassembled. 
The TC OH is added and terminated at the source and sink of the corresponding tandem 
connections, respectively. The specific OH format and coding is defined in 15.6 and 15.8. 

15.1 J Optical Channel Transport Unit Overhead (OTUk OH) 

OTUk OH information is part of the OTUk signal structure. It includes information for operational 
functions to support the transport via one or more Optical Channel connections. The OTUk OH is 
terminated where the OTUk signal is assembled and disassembled. The specific OH format and 
coding is defined in 15.6 and 15.7. 

The specific frame structure and coding for the non-standard OTUkV OH is outside the scope of 
this recommendation. Only the required basic functionality that has to be supported is defined in 
15.7.3. 

15.1.4 Optical Channel non-associated overhead (OCh OH) 

OCh OH information is added to the OTUk to create an OCh. It includes information for 
maintenance functions to support fault management. The OCh OH is terminated where the OCh 
signal is assembled and disassembled. 

The specific frame structure and coding for the OCh OH is outside the scope of this 
recommendation. Only the required basic functionality that has to be supported is defined in 15.5. 
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15.1.5 Optical Multiplex Section overhead (OMS OH) 

OMS OH information is added to the OCG to create an OMU. It includes information for 
maintenance and operational functions to support optical multiplex sections. The OMS OH is 
terminated where the OMU is assembled and disassembled. 

The specific frame structure and coding for the OMS OH is outside the scope of this 
recommendation. Only the required basic functionality that has to be supported is defined in 15.4. 

15.1.6 Optical Transmission Section overhead (OTS OH) 

OTS OH information is added to the information payload to create an OTM. It includes information 
for maintenance and operational functions to support optical transmission sections. The OTS OH is 
terminated where the OTM is assembled and disassembled. 

The specific frame structure and coding for the OTS OH is outside the scope of this 
recommendation. Only the required basic functionality that has to be supported is defined in 15.3. 

15.1.7 General management communications overhead (COMMS OH) 

COMMS OH information is added to the information payload to create an OTM. It provides general 
management communication between network elements. The specific frame structure and coding 
for the COMMS OH is outside the scope of this recommendation. 
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FIGURE 15-1/G.709 
OTSn, OMSn and OCh overhead as logical elements within the OOS 
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15.2 Trail Trace Identifier and Access Point Identifier definition 

A Trail Trace Identifier (TTI) is defined as a 64-byte string with the following structure 
(Figure 15-4): 

TTI[0] contains the SAPI[0] character, which is fixed to all-O's. 

TTI[1] to TTI[15] contain the 15 character Source Access Point Identifier (SAPI[1] to 

SAPI[15]). 

TTI[16] contains the DAPI[0] character, which is fixed to all-O's. 

TTI[17] to TTI[31] contain the 15 character Destination Access Point Identifier (DAPI[1] 
toDAPI[15]). 

TTI[32] to TTI[63] are Operator Specific. 
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FIGURE 15-4/G.709 
TTI structure 

The features of Access Point Identifiers (APIs) are: 

each access point identifier must be globally unique in its layer network; 
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where it may be expected that the access point may be required for path set-up across an 
inter-operator boundary, the access point identifier must be available to other network 
operators; 

the access point identifier should not change while the access point remains in existence; 
the access point identifier should be able to identify the country and network operator 
which is responsible for routing to and from the access point; 

the set of all access point identifiers belonging to a single administrative layer network 
should form a single access point identification scheme; 

the scheme of access point identifiers for each administrative layer network can be 
independent from the scheme in any other administrative layer network. 
It is recommended that the ODUk, OTUk and OTM should each have the access point identification 
scheme based on a tree-like format to aid routing control search algorithms. The access point 
identifier should be globally unambiguous. 

The Access Point Identifier (SAPI, DAPI) shall consist of a three-character International Segment 
and a twelve-character National Segment (NS) (Figure 15-5). These characters shall be coded 
according to Recommendation T.50 (International Reference Version - 7-bit coded character set for 
information exchange). 
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FIGURE 15-5/G.709 
Access Point Identifier structure 

The international segment field provides a 3 character ISO 3166 Geographic/Political Country Code 
(G/PCC). The country code shall be based on the three-character uppercase alphabetic ISO 3166 
Country Code (e.g. USA, FRA). 

The national segment field consists of two sub-fields: the ITU Carrier Code (ICC) followed by a 
Unique Access Point Code (UAPC). 

The ITU Carrier Code is a code assigned to a network operator/service provider, maintained by the 
ITU-T Telecommunication Service Bureau (TSB) in association with Recommendation M.1400. 
This code shall consist of 1-6 left-justified characters, alphabetic, or leading alphabetic with trailing 
numeric. 



ITU-T G.709 (10/2001)- 



Editor's version 



45 



The unique access point code shall be a matter for the organization to which the country code and 
ITU carrier code have been assigned, provided that uniqueness is guaranteed. This code shall 
consist of 6-1 1 characters, with trailing NUL, completing the 12-character National Segment. 

15.3 OTS OH description 

The following OTM-n OTSn overhead is defined: 
OTSn-TTI; 
OTSn-BDI-P; 
OTSn-BDI-O; 
OTSn-PMI. 

15.3.1 OTS Trail Trace Identifier (TTI) 

The OTSn-TTI is defined to transport a 64-byte TTI as specified in 15.2 for OTSn section 
monitoring. 

15.3.2 OTS Backward Defect Indication - Payload (BDI-P) 

For OTSn section monitoring, the OTSn-BDI-P signal is defined to convey in the upstream 
direction the OTSn payload signal fail status detected in the OTSn termination sink function. 

15.3.3 OTS Backward Defect Indication - Overhead (BDI-O) 

For OTSn section monitoring, the OTSn-BDI-0 signal is defined to convey in the upstream 
direction the OTSn overhead signal fail status detected in the OTSn termination sink function. 

15.3.4 OTS Payload Missing Indication (PMI) 

The OTS PMI is a signal sent downstream as an indication that upstream at the source point of the 
OTS signal no payload is added, in order to suppress the report of the consequential loss of signal 
condition. 

15.4 OMS OH description 

The following OTM-n OMSn overhead is defined: 
OMSn-FDI-P; 
OMSn-FDI-O; 
OMSn-BDI-P; 
OMSn-BDI-O; 
OMSn-PMI. 

15.4.1 OMS Forward Defect Indication - Payload (FDI-P) 

For OMSn section monitoring, the OMSn-FDI-P signal is defined to convey in the downstream 
direction the OMSn payload signal status (normal or failed). 

15.4.2 OMS Forward Defect Indication - Overhead (FDI-O) 

For OMSn section monitoring, the OMSn-FDI-0 signal is defined to convey in the downstream 
direction the OMSn overhead signal status (normal or failed). 
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15.4.3 OMS Backward Defect Indication - Payload (BDI-P) 

For OMSn section monitoring, the OMSn-BDI-P signal is defined to convey in the upstream 
direction the OMSn payload signal fail status detected in the OMSn termination sink function. 

15.4.4 OMS Backward Defect Indication - Overhead (BDI-O) 

For OMSn section monitoring, the OMSn-BDI-0 signal is defined to convey in the upstream 
direction the OMSn overhead signal fail status detected in the OMSn termination sink function. 

15.4.5 OMS Payload Missing Indication (PMI) 

The OMS PMI is a signal sent downstream as an indication that upstream at the source point of the 
OMS signal none of the OCCp's contain an optical channel signal, in order to suppress the report of 
the consequential loss of signal condition. 

15.5 OCh OH description 

The following OTM-n OCh overhead is defined: 
OCh-FDI-P; 
OCh-FDI-O; 
OCh-OCI. 

15.5.1 OCh Forward Defect Indication - Payload (FDI-P) 

For OCh trail monitoring, the OCh-FDI-P signal is defined to convey in the downstream direction 
the OCh payload signal status (normal or failed). 

15.5.2 OCh Forward Defect Indication - Overhead (FDI-O) 

For OCh trail monitoring, the OCh-FDI-O signal is defined to convey in the downstream direction 
the OCh overhead signal status (normal or failed). 

15.5.3 OCh Open Connection Indication (OCI) 

The OCh OCI is a signal sent downstream as an indication that upstream in a connection function 
the matrix connection is opened as a result of a management command. The consequential detection 
of the OCh loss of signal condition at the OCh termination point can now be related to an open 
matrix. 

15.6 OTUk/ODUk Frame Alignment OH description 
15.6.1 OTUk/ODUk frame alignment overhead location 

The OTUk/ODUk frame alignment overhead location is shown in Figure 15-6. The OTUk/ODUk 
frame alignment overhead is applicable for both the OTUk and ODUk signals. 
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FIGURE 15-6/G.709 
OTUk/ODUk frame alignment overhead 



15.6.2 OTUk/ODUk frame alignment overhead definition 
15.6.2.1 Frame Alignment Signal (FAS) 

A six byte OTUk-FAS signal (Figure 15-7) is defined in row 1, columns 1 to 6 of the OTUk 
overhead. OAl is "1111 01 10". OA2 is "0010 1000". 
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FIGURE 15-7/G.709 
Frame Alignment Signal Overhead structure 



15.6.2.2 Multi Frame Alignment Signal (MFAS) 

Some of the OTUk and ODUk overhead signals will span multiple OTUk/ODUk frames. Examples 
are the TTI and TCM-ACT overhead signals. These and other multi-frame structured overhead 
signals require multi-frame alignment processing to be performed, in addition to the OTUk/ODUk 
frame alignment. 

A single multi-frame alignment signal (MFAS) byte is defined in row 1 , column 7 of the 
OTUk/ODUk overhead for this purpose (Figure 15-8). The value of the MFAS byte will be 
incremented each OTUk/ODUk frame and provides as such a 256 frame multi-frame. 
Individual OTUk/ODUk overhead signals may use this central multi-frame to lock their 2-frame, 
4-frame, 8-frame, 16-frame, 32-frame, etc. multi-frames to the principal frame. 
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FIGURE 15-8/G.709 
Multi-Frame Alignment Signal Overhead 

15.7 OTUk OH description 
15.7.1 OTUk overhead location 

The OTUk overhead location is shown in Figure 15-9 and Figure 15-10. 
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OTUk Overhead 
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FIGURE 15-10/G.709 
OTUk Section Monitoring overhead 
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15.7.2 OTUk overhead definition 

15.7.2.1 OTUk Section Monitoring (SM) Overhead 

One field of OTUk Section Monitoring (SM) Overhead is defined in row 1, columns 8 to 10 to 
support section monitoring. 

The SM field contains the following subfields (Figure 15-10): 
Trail Trace Identifier (TTI); 
Bit Interleaved Parity (BIP-8); 
Backward Defect Indication (BDI); 

Backward Error Indication and Backward Incoming Alignment Error (BEI /BIAE ) ; 
Incoming Alignment Error (IAE); 

Bits reserved for future international standardization (RES). 

15.7.2.1.1 OTUk SM Trail Trace Identifier (TTI) 

For section monitoring, a one byte Trail Trace Identifier (TTI) overhead is defined to transport the 
64-byte TTI signal specified in 15.2. 

The 64-byte TTI signal shall be aligned with the OTUk multiframe (see 15.6.2.2) and transmitted 
four times per multiframe. Byte 0 of the 64-byte TTI signal shall be present at OTUk multiframe 
positions 0000 0000 (0x00), 0100 0000 (0x40), 1000 0000 (0x80) and 1 100 0000 (OxCO). 

15.7.2.1.2 OTUk SM Error Detection Code (BIP-8) 

For section monitoring a one byte Error Detection Code signal is defined. This byte provides a Bit 
Interleaved Parity-8 (BIP-8) code. 

NOTE - The notation BIP-8 refers only to the number of BIP bits and not to the EDC usage 
(i.e. what quantities are counted). 

The OTUk BIP-8 is computed over the bits in the OPUk (columns 15 to 3824) area of OTUk 
frame i, and inserted in the OTUk BIP-8 overhead location in OTUk frame i+2 (Figure 15-11). 
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FIGURE 1 5-1 1/G.709 
OTUk SM BIP-8 computation 



15.7.2.1 .3 OTUk SM Backward Defect Indication (BDI) 

For section monitoring, a single bit Backward Defect Indication (BDI) signal is defined to convey 
the signal fail status detected in a section termination sink function in the upstream direction. 
BDI is set to "1" to indicate an OTUk backward defect indication, otherwise it is set to "0". 

15.7.2.1.4 OTUk SM Backward Error inH.Tatinn and Backward Incoming Alignment Error 
(BE I/B1AE) 

For section monitoring, a four bit Backward Error Indication (BED and Backward Incoming 
Alignment FiTor(BIAE) signal is defined This signal is used to convey in the upstream direction 
the count of interleaved-bit blocks that have been detected in error by the corresponding OTUk 
section monitoring sink using the BIP-8 code. It is also used to convey in the upstream direction an 
incoming alignment error (IAE) co n dition that is detected in the corresponding OTUk section 
monitoring sink in the IAE overhead. 

During a IAE condition the code "101 1 " is inserted into the BE1/BIAE field and the error count is 
SB Otherwise flj error count (0-8) is inserted into the BEI/B1AE faddThs count has m* 
IluiI ■ to namolv 0 i nmr. The remaining ^-six possible values represented by these Jour 
bits can only result'from some unrelated condition and shall be interpreted as zero errors (Table 15- 
ll andBlAEnot active . 
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TABLE 15-1/G.709 
OTUk SM BEI /B1AE interpretation 



OTUkSM 

DILI/ r>i /-\.JL 

bits 
1234 


BIAE 


BEP violations 


0000 


false 


0 


0001 


false 


1 


0010 


false 


2 


0011 


false 


3 


0100 


false 


4 


0101 


false 


5 


0110 


false 


6 


0111 


false 


7 


1000 


false 


8 


1001. 1010 


false 


0 


1011 


true 


g 


lj004- to 1111 


false 


0 



15.7.2.1.5 OTUk SM Incoming Alignment Error overhead (IAE) 

A single bit incoming alignment error (IAE) signal is defined to allow the S-CMEP ingress point to 
inform its peer S-CMEP egress point that an alignment error in the incoming signal has been 
detected. 

IAE is set to "1" to indicate a frame alignment error, otherwise it is set to "0". 

The S-CMEP egress point may use this information to suppress the counting of bit errors, which 
may occur as a result of a frame phase change of the OTUk at the ingress of the section. 

15.7.2.1.6 OTUk SM Reserved overhead (RES) 

For section monitoring, two bits are reserved (RES) for future international standardization. They 
are set to "00". 

15.7.2.2 OTUk General Communication Channel 0 (GCC0) 

Two bytes are allocated in the OTUk Overhead to support a General Communications Channel 
between OTUk termination points. This is a clear channel and any format specification is outside of 
the scope of this recommendation. These bytes are located in row 1, columns 1 1 and 12 of the 
OTUk overhead. 

15.7.2.3 OTUk Reserved overhead (RES) 

Two bytes of OTUk overhead are reserved for future international standardization. These bytes are 
located in row 1, columns 13 and 14. These bytes are set to all ZEROs. 
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15.7.3 OTUkV overhead 

The functionally standardised OTUkV frame should support, as a minimum capability, section 
monitoring functionality comparable to the OTUk section monitoring (15.7.2.1) with a trail tec 
identifier as specified in 15.2. Further specification of this overhead is outside the scope of this 
Recommendation. 

15.8 ODUk OH description 
15.8.1 ODUk OH location 

The ODUk overhead location is shown in Figure 15-12, Figure 15-13 and Figure 15-14. 



Column # 




FIGURE 15-12/G.709 
ODUk Overhead 
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FIGURE 15-13/G.709 
ODUk Path Monitoring overhead 
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FIGURE 15-14/G.709 
ODUk Tandem Connection Monitoring #i overhead 

15.8.2 ODUk OH definition 

1 5.8.2.1 ODUk Path Monitoring (PM) Overhead 

One field of ODUk Path Monitoring Overhead (PM) is defined in row 3, columns 10 to 12 to 
support path monitoring. 
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The PM field contains the following subfields (Figure 15-1 3): 
Trail Trace Identifier (TTI); 
Bit Interleaved Parity (BIP-8); 
Backward Defect Indication (BDI); 
Backward Error Indication (BEI); 

Status bits indicating the presence of a maintenance signal (STAT). 

The content of the PM field, except the STAT subfield, will be undefined (pattern will be all-l's, 
01 10 01 10 or 0101 0101 repeating) during the presence of a maintenance signal (e.g. ODUk-AIS, 
ODUk-OCI, ODUk-LCK). Refer to 16.5. 

15.8.2.1.1 ODUk PM Trail Trace Identifier (TTI) 

For path monitoring, a one byte Trail Trace Identifier (TTI) overhead is defined to transport the 
64-byte TTI signal specified in 15.2. 

The 64-byte TTI signal shall be aligned with the ODUk multiframe (see 15.6.2.2) and transmitted 
four times per multiframe. Byte 0 of the 64-byte TTI signal shall be present at ODUk multiframe 
positions 0000 0000 (0x00), 0100 0000 (0x40), 1000 0000 (0x80) and 1 100 0000 (OxCO). 

15.8.2.1.2 ODUk PM Error Detection Code (BIP-8) 

For path monitoring, a one byte Error Detection Code signal is defined. This byte provides a Bit 
Interleaved Parity-8 (BIP-8) code. 

NOTE - The notation BIP-8 refers only to the number of BIP bits and not to the EDC usage 
(i.e. what quantities are counted). 

Each ODUk BIP-8 is computed over the bits in the OPUk (columns 15 to 3824) area of ODUk 
frame i, and inserted in the ODUk PM BIP-8 overhead location in the ODUk frame i+2 
(Figure 15-15). 
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FIGURE 15-15/G.709 
ODUk PM BIP-8 computation 



15.8.2.1.3 ODUk PM Backward Defect Indication (BDI) 

For path monitoring, a single bit Backward Defect Indication (BDI) signal is defined to convey the 
signal fail status detected in a path termination sink function in the upstream direction. 
BDI is set to "1" to indicate an ODUk backward defect indication, otherwise it is set to "0". 

15.8.2.1.4 ODUk PM Backward Error Indication (BEI) 

For path monitoring, a four bit Backward Error Indication (BEI) signal is defined to convey in the 
upstream direction the count of interleaved-bit blocks that have been detected in error by the 
corresponding ODUk path monitoring sink using the BIP-8 code. This count has nine legal values, 
namely 0-8 errors. The remaining seven possible values represented by these four bits can only 
result from some unrelated condition and shall be interpreted as zero errors (Table 15-2). 



TABLE 15-2/G.709 
ODUk PM BEI interpretation 



ODUk PM BEI 


BIP violations 


bits 




1234 




0000 


0 


0001 


1 


0010 


2 


0011 


3 
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0100 


4 


0101 


5 


0110 


6 


0111 


7 


1000 


8 


looi to nil 


0 



15.8.2.1.5 ODUk PM Status (STAT) 

For path monitoring three bits are defined as status bits (STAT). They indicate the presence of a 
maintenance signal (Table 15-3). 

A P-CMEP sets these bits to "001". 



TABLE 15-3/G.709 
ODUk PM Status interpretation 



PM byte 3, 
bits 678 


status 


000 


reserved for future international standardisation 


001 


normal path signal 


010 


reserved for future international standardisation 


011 


reserved for future international standardisation 


100 


reserved for future international standardisation 


101 


maintenance signal: ODUk-LCK 


110 


maintenance signal: ODUk-OCI 


111 


maintenance signal: ODUk-AIS 



15.8.2.2 ODUk Tandem Connection Monitoring (TCM) Overhead 

Six fields of ODUk Tandem Connection Monitoring (TCM) overhead are defined in row 2, 
columns 5 to 13 and row 3, columns 1 to 9 of the ODUk overhead. TCM supports monitoring of 
ODUk connections for one or more of the following network applications (refer to 
Recommendations G.805 and G.872): 

- optical UNI to UNI tandem connection monitoring; monitoring the ODUk connection 
through the public transport network (from public network Ingress Network Termination to 
Egress Network Termination); 

- optical NNI to NNI tandem connection monitoring; monitoring the ODUk connection 
through the network of a network operator (from operator network Ingress Network 
Termination to Egress Network Termination); 

sublayer monitoring for linear 1+1 , 1 : 1 and 1 :n optical channel subnetwork connection 
protection switching, to determine the Signal Fail and Signal Degrade conditions; 
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sublayer monitoring for optical channel shared protection ring (SPring) protection 

switching, to determine the Signal Fail and Signal Degrade conditions; 

monitoring an optical channel tandem connection for the purpose of detecting a signal fail 

or signal degrade condition in a switched optical channel connection, to initiate automatic 

restoration of the connection during fault and error conditions in the network; 

monitoring an optical channel tandem connection for e.g. fault localisation or verification 

of delivered quality of service. 
The six TCM fields are numbered TCM1, TCM2, .., TCM6. 
Each TCM field contains the following subfields (Figure 15-14): 

Trail Trace Identifier (TTI); 

Bit Interleaved Parity 8 (BIP-8); 

Backward Defect Indication (BDI); 

Backward Error Indication and Backward Incoming Alignment Error (BEI/B1AE); 
Status bits indicating the presence of TCM overhead, Incoming Alignment Error, or a 
maintenance signal (STAT). 

The content of the TCM fields, except the STAT subfield, will be undefined (pattern will be all-l's, 
01100110 or 01010101 repeating) during the presence of a maintenance signal (e.g. ODUk-AIS, 
ODUk-OCI, ODUk-LCK). Refer to 16.5. 

A TCM field is assigned to a monitored connection as described in 15.8.2.2.6. The number of 
monitored connections along an ODUk trail may vary between 0 and 6. Monitored connections can 
be nested overlapping and/or cascaded. Nesting and cascading is shown in Figure 15-16. Monitored 
connections A1-A2/B1-B2/C1-C2 and A1-A2/B3-B4 are nested, while B1-B2/B3-B4 are cascaded. 
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FIGURE 15-16/G.709 
Example of nested and cascaded ODUk monitored connections 



Overlapping monitored connections as shown in Figure 15-17 (B1-B2 and C1-C2) are also 
supported. 
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FIGURE 15-17/G.709 
Example of overlapping ODUk monitored connections 



15.8.2.2.1 ODUk TCM Trail Trace Identifier (TTI) 

For each tandem connection monitoring field, one byte of overhead is allocated for the transport c 
the 64-byte Trail Trace Identifier (TTI) specified in 15.2. 

The 64-byte TTI signal shall be aligned with the ODUk multiframe (see 15.6.2.2) and transmitted 
four times per multiframe. Byte 0 of the 64-byte TTI signal shall be present at ODUk multiframe 
positions 0000 0000 (0x00), 0100 0000 (0x40), 1000 0000 (0x80) and 1100 0000 (OxCO). 

1 5.8.2.2.2 ODUk TCM Error Detection Code (BIP-8) 

For each tandem connection monitoring field, a one byte Error Detection Code signal is defined. 
This byte provides a Bit Interleaved Parity-8 (BIP-8) code. 

NOTE - The notation BIP-8 refers only to the number of BIP bits, and not to the EDC usage 
(i.e. what quantities are counted). 

Each ODUk BIP-8 is computed over the bits in the OPUk (columns 15 to 3824) area of ODUk 
frame i, and inserted in the ODUk TCM BIP-8 overhead location (associated with the tandem 
connection monitoring level) in ODUk frame i+2 (Figure 15-18). 
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FIGURE 15-18/G.709 
ODUk TCM BIP-8 computation 



15.8.2.2.3 ODUk TCM Backward Defect Indication (BDI) 

For each tandem connection monitoring field, a single bit Backward Defect Indication (BDI) signal 
is defined to convey the signal fail status detected in a tandem connection termination sink function 
in the upstream direction. 

BDI is set to "1" to indicate an ODUk backward defect indication, otherwise it is set to "0". 

15.8.2.2.4 ODUk TCM Backward Error Indicatio n and Backward Incoming Alignment 
Error (BEI /B1AE ) 

For each tandem connection monitoring field, a 4-bit Backward Error Indication (BEI) and 
Backward Incoming Alignment Error (BIAE) signal is define d. This signal is used to convey in the 
upstream direction the count of interleaved-bit blocks that have been detected as being in error by 
the corresponding ODUk tandem connection monitoring sink using the BIP-8 code. It is also used 
to convey in the upstream direction an incoming alignment error (1AE) condition that is detected in 
the corresponding ODUk tandem connection monitoring sink in the 1AE overhead. 

During a 1AE condition the code "101 1" is inserted into the BE1/BIAE field and the error count is 
ignored. Otherwise the error count (0-8) is inserted into the BEI/B1AE field. Thio count has nine 
legal values, namely 0 8 errors. The remaining seven-six possible values represented by these four 
bits can only result from some unrelated condition and shall be interpreted as zero errors (Table 15- 
4 ) and BIAE not active . I 
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TABLE 15-4/G.709 
ODUk TCM BEI /BIAE interpretation 



ODUkTCM 

DT7T /DT A F 

bits 
1234 


BIAE 


BD? violations 


0000 


false 


0 


0001 


false 


1 


0010 


false 


2 


0011 


false 


3 


0100 


false 


4 


0101 


false 


5 


0110 


false 


6 


0111 


false 


7 1 


1000 


false 


8 


1001. 1010 


false 


0 


1011 


true 


0 


11004- to 1111 


false 


0 



15.8.2.2.5 ODUk TCM Status (STAT) 

For each tandem connection monitoring field three bits are defined as status bits (STAT). They 
indicate the presence of a maintenance signal, if there is an incoming alignment error at the source 
TC-CMEP, or if there is no source TC-CMEP active (Table 15-5). 

A P-CMEP sets these bits to "000". 

A TC-CMEP ingress point sets these bits to either "001" to indicate to its peer TC-CMEP egress 
point that there is no Incoming Alignment Error (IAE), or to "010" to indicate that there is an 
Incoming Alignment Error. 

The TC-CMEP egress point may use this information to suppress the counting of bit errors, which 
may occur as a result of a frame phase change of the ODUk at the ingress of the tandem connection. 



TABLE 15-5/G.709 
ODUk TCM Status interpretation 



TCM byte 3, 
bits 678 


Status 


000 


no source TC 


001 


in use without IAE 


010 


in use with IAE 


011 


reserved for future international standardisation 


100 


reserved for future international standardisation 


101 


maintenance signal: ODUk-LCK 


110 


maintenance signal: ODUk-OCI 
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1 1 1 maintenance signal: ODUk-AIS 



15.8*2.2.6 TCM overhead field assignment 

Each TC-CMEP will be inserting/extracting its TCM overhead from one of the 6 TCMj overhead 
fields. The specific TCMj overhead field is provisioned by the network operator, network 
management system or switching control plane. 

At a domain interface, it is possible to provision the maximum number (0 to 6) of tandem 
connection levels which will be passed through the domain. The default is three. These tandem 
connections should use the lower TCMi overhead fields TCMi.TCMmax- Overhead in TCM fields 
beyond the maximum (TCNUx+i and above) may/will be overwritten in the domain. 
Example - For the case of a ODUk leased circuit, the user may have been assigned one level of 

TCM, the Service Provider one level of TCM and each network operator (having a contract 
with the service provider) 4 levels of TCM. For the case a network operator subcontracts 
part of its ODUk connection to another network operator, these 4 levels are to be split; e.g. 
2 levels for the subcontracting operator. 

This would result in the following TCM OH allocation: 

- User: TCMI overhead field between the two user subnetworks, and TCMI ..TCM6 
within its own subnetwork. 

- Service Provider (SP): TCM2 overhead field between two UNIs 

- Network Operators NO 1 , N02, N03 having contract with Service Provider: TCM3, 
TCM4, TCM5, TCM6. Note that N02 (which is subcontracting) can not use TCM5 and 
TCM6 in the connection through the domain of N04. 

- N04 (having subcontract with N02): TCM5, TCM6. 
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FIGURE 15-19/G.709 
Example of TCM overhead field assignment 



ITU-T G.709 (10/2001)- 



Editor's version 



66 



15.8.2.2.7 ODUk Tandem Connection Monitoring Activation/Deactivation coordination 
protocol 

A one-byte TCM Activation/Deactivation field is located in row 2, column 4. Its definition is for 
further study. 

15.8.2.3 ODUk General Communication Channels (GCC1, GCC2) 

Two fields of two bytes are allocated in the ODUk Overhead to support two General 
Communications Channels between any two network elements with access to the ODUk frame 
structure (i.e. at 3-R regeneration points). These are clear channels and any format specification is 
outside of the scope of this Recommendation. The bytes for GCC1 are located in row 4, columns 1 
and 2, and the bytes for GCC2 are located in bytes row 4, columns 3 and 4 of the ODUk overhead. 

15.8.2.4 ODUk Automatic Protection Switching and Protection Communication Channel 
(APS/PCC) 

A four byte ODUk-APS/PCC signal is defined in row 4, columns 5 to 8 of the ODUk overhead. 
One or more levels of nested APS/PCC signals may be defined in this field. This is for further 
study. 

15.8.2.5 ODUk Fault type and fault location reporting communication channel (FTFL) 

One byte is allocated in the ODUk overhead to transport a 256-byte Fault Type and Fault Location 
(FTFL) message. The byte is located in row 2, column 14 of the ODUk overhead. 
The 256-byte FTFL message shall be aligned with the ODUk multiframe (i.e. byte 0 of the 256-byte 
FTFL message shall be present at ODUk multiframe position 0000 0000, byte 1 of the 256-byte 
FTFL message shall be present at ODUk multiframe position 0000 0001, byte 2 of the 256-byte 
FTFL message shall be present at ODUk multiframe position 0000 0010, etc.). 

The 256-byte FTFL message consists of two 128-byte fields as shown in Figure 15-20: the forward 
and backward field. The forward field is allocated to bytes 0 through 127 of the FTFL message. The 
backward field is allocated to bytes 128 through 255 of the FTFL message. 



127 128 129 



255 
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Backward field 



T1 542690-00 
(114739) 



FIGURE 15-20/G.709 
FTFL Message Structure 

The forward and backward fields are further divided into three subfields as shown in Figure 15-21: 
the forwardftackward fault type indication field, the forwardftackward operator identifier field, and 
the forwardftackward operator specific field. 
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FIGURE 15-21/G.709 
Forward/Backward Field Structure 



15.8.2.5.1 Forward/Backward Fault Type Indication Field 

The fault type indication field provides the fault status. Byte-0 of the FTFL message is allocated for 
the forward fault type indication field. Byte 128 of the FTFL message is allocated for die backward 
fault type indication field. The fault type indication fields are coded as in Table 15-6. Code 
0000 0000 shall indicate No Fault, code 0000 0001 shall indicate Signal Fail, and code 0000 0010 
shall indicate Signal Degrade. The remaining codes are reserved for future international 
standardisation. 



TABLE 15-6/G.709 



Fault Indication Codes 



Fault Indication Code 


Definition 


0000 0000 


No Fault 


0000 0001 


Signal Fail 


0000 0010 


Signal Degrade 



0000 0011 



Reserved for Future 
International Standardisation 



1111 1111 



15.8.2.5.2 Forward/Backward Operator Identifier Field 

The operator identifier field is 9 bytes. Bytes 1 through 9 are allocated for the forward operator 
identifier field. Bytes 129 through 137 are allocated for the backward operator identifier field. T 
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operator identifier field consists of two subfields: the international segment field, and the national 
segment field as shown in Figure 15-22. 

The international segment field provides a three character ISO 3166 Geographic/Political Country 
Code (G/PCC). The first three bytes of the 9-byte operator identifier field (i.e. bytes 1 through 3 for 
the forward operator identifier field and bytes 129 through 131 for the backward operator identifier 
field) are reserved for the international segment field. The country code shall be based on the 
three-character uppercase alphabetic ISO 3166 Country Code (e.g. USA, FRA). 

The national segment field provides a 1-6 character ITU Carrier Code (ICC). The ICC is maintained 
by the ITU-T Telecommunication Service Bureau (TSB) in association with ITU-T 
Recommendation M.1400. The national segment field is 6 bytes and provides a 1-6 character 
ITU Carrier Code (ICC) with trailing null characters to complete the 6 character field. 
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FIGURE 15-22/G.709 
Operator Identifier Field Structure 



15.8.2.6.3 Forward/Backward Operator Specific Field 

Bytes 10 through 127 are allocated for the forward operator specific field as shown in Figure 15-21. 
Bytes 138 through 255 are allocated for the backward operator specific field. The operator specific 
fields are not subject to standardization. 

15.8.2.6 ODUk Experimental Overhead (EXP) 

Two bytes are allocated in the ODUk overhead for experimental use. These bytes are located in 
row 3, columns 13 and 14 of the ODUk overhead. 

The use of these bytes is not subject to standardization and outside the scope of this 
Recommendation. 

Experimental overhead is provided in the ODUk OH to allow a vendor and/or a network operator 
within their own (sub)network to support an application, which requires additional ODUk overhead. 
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There is no requirement to forward the EXP overhead beyond the (sub)network, i.e. the operational 
span of the EXP overhead is limited to the (sub)network with the vendor's equipment, or the 
network of the operator. 

15.8.2.7 ODUk Reserved overhead (RES) 

Nine bytes are reserved in the ODUk overhead for future international standardization. These bytes 
are located in row 2, columns 1 to 3 and row 4, columns 9 to 14 of the ODUk overhead. These bytes 
are set to all ZEROs. 



15.9 OPUk OH description 
15.9.1 OPUk OH location 

The OPUk overhead consists of: Payload Structure Identifier (PSI) including the Payload Type 
(PT), overhead associated with concatenation and overhead (e.g. justification control and 
opportunity bits) associated with the mapping of client signals into the OPUk payload. The OPUk 
PSI and PT overhead locations are shown in Figure 15-23. 
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FIGURE 15-23/G.709 
OPUk overhead 

15.9.2 OPUk OH definition 

15.9.2.1 OPUk Payload Structure Identifier (PSI) 

One byte is allocated in the OPUk overhead to transport a 256-byte Payload Structure Identifier 
(PSI) signal. The byte is located in row 4, column 15 of the OPUk overhead. 

The 256-byte PSI signal is aligned with the ODUk multiframe (i.e. PSI[0] is present at ODUk 
multiframe position 0000 0000, PSI[1] at position 0000 0001, PSI[2] at position 0000 0010, etc.). 

PSI[0] contains a one byte Payload Type. PSI[1] to PSI[255] are mapping and concatenation 
specific rosorvod for future international standardization (RES) , except for PT 0x01 (experimental 
mapping) and PTs 80-0x8F (for proprietary use). 

15.9.2.1.1 OPUk Payload Type (PT) 

A one byte Payload Type signal is defined in the PSI[0] byte of the Payload Structure Identifier to 
indicate the composition of the OPUk signal. The code points are defined in Table 15-7. 
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TABLE 15-7/G.709 



Payload Type code points 



MaB 
1234 


5678 


rxcA tuuc 
(NOTE 1) 


Interpretation 


0000 


000 1 


01 


Experimental mapping (NOTE 3) 


0000 


0010 


02 


asynchronous STM-N mapping, see 17.1 


0000 


001 1 


03 


bit synchronous STM-N mapping, see 17.1 


0000 


0100 


04 


ATM mapping, see 17.2 


0000 


0101 


05 


GFP mapping, see 17.3 


0000 


0 110 


06 


Virtual Concatenated signal, see 18 (NOTE 5} 


0001 


0000 


10 


bit stream with octet timing mapping, see 17.5.1 


000 1 


0001 


11 


bit stream without octet timing mapping, see 17.5.2 


00 10 


0 0 0 0 


20 


ODU multiplex structure, see 19 


0101 


0101 


55 


Not available (NOTE 2) 


0110 


0110 


66 


Not available (NOTE 2) | 


1000 


xxxx 


80-8F 


reserved codes for proprietary use (NOTE 4) 


1111 


1101 


FD 


NULL test signal mapping, see 17.4.1 


1 1 1 1 


1110 


FE 


PRBS test signal mapping, see 17.4.2 


1111 


1111 


FF 


Not available (NOTE 2) 


NOTE 1 - There are 2286 spare codes left for fiiture international standardisation. 

NOTE 2 - These values are excluded ftom the set of available code points. These bit patterns are 

present in ODUk maintenance signals. 

NOTE 3 - Value "01 " is only to be used in cases where a mapping code is not denned in the above 
table. By using this code, the development (experimental) activities do not impact the OTN network. 
There is no forward compatibility if a specific payload type is assigned later. If a new code is 
assigned, equipment using this code shall be reconfigured to use the new code. 
NOTE 4 - These 16 code values will not be subject to standardization. 

NOTE S - For the pavload tvpe of the virtual concatenated signal a dedicated Davload tvoe overhead 


fvcPT) is used, see 1 8. 



15.9.2.1.2 OPUk Payload Structure Identifier Reserved overhead (RES) 

255 bytes are reserved in the OPUk PSI for future international standardization, except for the case 
of PT codes 0x01, 0x80 0x8F. Those bytes are located in PSI[1] to [PSI255] of the OPUk overhead. 
Those bytes are set to all ZEROs. 

15.9,2.2 OPUk Mapping specific Overhead 

Seven bytes are reserved in the OPUk overhead for mapping and concatenation specific overhead. 
These bytes are located in rows 1 to 3, columns 15 and 16 and row 4 column 16. In addition, 255 
bvtes in the PSI are reserved for mapping and concatenation s pecific purposes. 
The use of these bytes depends on the specific client signal mapping (defined in Hand 19) and the 
use of concatenation (see 18) . 
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16 Maintenance signals 

An Alarm Indication Signal (AIS) is a signal sent downstream as an indication that an upstream 
defect has been detected. An AIS signal is generated in an adaptation sink fimction. An AIS signal 
is detected in a trail termination sink function to suppress defects or failures that would otherwise be 
detected as a consequence of the interruption of the transport of the original signal at an upstream 
point. 

A Forward Defect Indication (FDI) is a signal sent downstream as an indication that an upstream 
defect has been detected. An FDI signal is generated in an adaptation sink function. An FDI signal 
is detected in a trail termination sink function to suppress defects or failures that would otherwise be 
detected as a consequence of the interruption of the transport of the original signal at an upstream 
point. 

NOTE - AIS and FDI are similar signals. AIS is used as term when the signal is in the digital 
domain. FDI is used as the term when the signal is in the optical domain; FDI is transported as 
non-associated overhead in the OlM Overhead Signal (OOS). 

An Open Connection Indication (OCI) is a signal sent downstream as an indication that upstream 
the signal is not connected to a trail termination source. An OCI signal is generated in a connection 
function and output by this connection function on each of its output connection points, which are 
not connected to one of its input connection points. An OCI signal is detected in a trail termination 
sink function. 

A Locked (LCK) is a signal sent downstream as an indication that upstream the connection is 
"locked", and no signal is passed through. 

A Payload Missing Indication (PMI) is a signal sent down stream as an indication that upstream at 
the source point of the signal, either none of the tributary slots have an optical signal or an optical 
signal with no payload. This indicates that the transport of the optical tributary signal is interrupted. 

A PMI signal is generated in the adaptation source function and it is detected in the trail termination 
sink function which suppresses the LOS defect that arises under this condition. 

16.1 OTS maintenance signals 

16.1.1 OTS Payload Missing Indication (OTS-PMI) 

OTS-PMI is generated as an indication that the OTS Payload does not contain an optical signal. 

16.2 OMS maintenance signals 

Three OMS maintenance signals are defined: OMS-FDI-P, OMS-FDI-0 and OMS-PMI. 

16.2.1 OMS Forward Defect Indication - Payload (OMS-FDI-P) 

OMS-FDI-P is generated as an indication of an OMS server layer defect in the OTS network layer. 

16.2.2 OMS Forward Defect Indication - Overhead (OMS-FDI-O) 

OMS-FDI-O is generated as an indication when the transport of OMS OH via the OOS is 
interrupted due to a signal fail condition in the OOS. 

16.2.3 OMS Payload Missing Indication (OMS-PMI) 

OMS-PMI is generated as an indication when none of the OCCs contain an optical signal. 
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16.3 OCh maintenance signals 

Three OCh maintenance signals are defined: OCh-FDI-P, OCh-FDI-0 and OCh-OCI. 

16.3.1 OCh Forward Defect Indication - Payload (OCh-FDI-P) 

OCh-FDI is generated as an indication for an OCh server layer defect in the OMS network layer. 
When the OTUk is terminated, the OCh-FDI is continued as an ODUk-AIS signal. 

16.3.2 OCh Forward Defect Indication - Overhead (OCh-FDI-O) 

OCh-FDI-0 is generated as indication when the transport of OCh OH via the OOS is interrupted 
due to a signal fail condition in the OOS. 

16.3.3 OCh Open Connection Indication (OCh-OCI) 

The OCh-OCI signal indicates to downstream transport processing functions that the OCh 
connection is not bound to, or not connected (via a matrix connection) to a termination source 
function. The indication is used in order to distinguish downstream between a missing optical 
channel due to a defect or due to the open connection (resulting from a management command). 
NOTE - OCI is detected at the next downstream OTUk trail terminating equipment. If the 
connection was opened intentionally, the related alarm report from this trail termination should be 
disabled by using the Alarm Reporting Control mode (refer to M.3100 Amendment 3). 

16.4 OTUk maintenance signals 

16.4.1 OTUk Alarm Indication Signal (OTUk-AIS) 

The OTUk-AIS (Figure 16-1) is a generic-AIS signal (16.6.1). Since the OTUk capacity 

(130560 bit) is not an integer multiple of the PN-1 1 sequence length (2047 bit), the PN-1 1 sequence 

may cross an OTUk frame boundary. 

NOTE - OTUk-AIS is defined to support a future server layer application. OTN equipment should 
be capable to detect the presence of such signal; it is not required to generate such signal. 



4080 



FIGURE 16-1/G.709 
OTUk-AIS 



16.5 ODUk maintenance signals 

Three ODUk maintenance signals are defined: ODUk-AIS, ODUk-OCI and ODUk-LCK. 
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16.5.1 ODUk Alarm Indication Signal (ODUk-AIS) 

ODUk-AIS is specified as all "l"s in the entire ODUk signal, excluding the Frame Alignment 
overhead (FA OH), OTUk overhead (OTUk OH) and ODUk FTFL (Figure 16-2). 

In addition, the ODUk-AIS signal may be extended with one or more levels of ODUk tandem 
connection, GCC1, GCC2, EXP and/or APS/PCC overhead before it is presented at the OTM 
interface. This is dependent on the functionality between the ODUk-AIS insertion point and the 
OTM interface. 

The presence of ODUk-AIS is detected by monitoring the ODUk STAT bits in the PM and TCMi 
overhead fields. 



FA OH OTUk OH 
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FIGURE 16-2/G.709 
ODUk-AIS 



16.5.2 ODUk Open Connection Indication (ODUk-OO) 

ODUk-OCI is specified as a repeating "0110 0110" pattern in the entire ODUk signal, excluding the 
Frame Alignment overhead (FA OH) and OTUk overhead (OTUk OH) (Figure 16-3). 

NOTE - The repeating "0110 0110" pattern is the default pattern; other patterns are also allowed as 
long as the STAT bits in the PM and TCMi overhead fields are set to "110". 

In addition, the ODUk-OCI signal may be extended with one or more levels of ODUk tandem 
connection, GCC1, GCC2, EXP and/or APS/PCC overhead before it is presented at the OTM 
interface. This is dependent on the functionality between the ODUk-OCI insertion point and the 
OTM interface. 

The presence of ODUk-OCI is detected by monitoring the ODUk STAT bits in the PM and TCMi 
overhead fields. 
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FIGURE 16-3/G.709 
ODUk-OCI 



16.5.3 ODUk Locked (ODUk-LCK) 

ODUk-LCK is specified as a repeating "0101 0101" pattern in the entire ODUk signal, excluding 
the Frame Alignment overhead (FA OH) and OTUk overhead (OTUk OH) (Figure 16-4). 
NOTE - The repeating "0101 0101" pattern is the default pattern; other patterns are also allowed as 
long as the STAT bits in the PM and TCMi overhead fields are set to "101". 
In addition, the ODUk-LCK signal may be extended with one or more additional levels of ODUk 
tandem connection, GCC1, GCC2, EXP and/or APS/PCC overhead before it is presented at the 
OTM interface. This is dependent on the functionality between the ODUk-LCK insertion point and 
the OTM interface. 

The presence of ODUk-LCK is detected by monitoring the ODUk STAT bits in the PM and TCMi 
overhead fields. 




FIGURE 16-4/G.709 
ODUk-LCK 
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16.6 Client maintenance signal 

16.6.1 Generic AIS for constant bit rate signals 

The generic-AIS signal is a signal with a 2047-bit Polynomial Number 1 1 (PN-1 1) repeating 
sequence. 

The PN-1 1 sequence is defined by the generating polynomial 1 + x 9 + x 1 1 as specified in 5.2/0. 150. 
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FIGURE 16-5/G.709 
Generic-AIS generating circuit 



1 7 Mapping of client signals 

17.1 Mapping of CBR2G5, CBR10G and CBR40G signals (e.g. STM-16/64/256) into OPUk 

Mapping of a CBR2G5, CBR10G or CBR40G signal (with up to ±20 ppm bit-rate tolerance) into an 
OPUk (k= 1,2,3) may be performed according two different modes (asynchronous and bit 
synchronous) based on one generic OPUk frame structure (Figure 17-1). 

NOTE 1 - Examples of such signals are STM-16, STM-64 and STM-256. 

NOTE 2 - The maximum bit-rate tolerance between OPUk and the client signal clock, which can be 
accommodated by this mapping scheme, is ±65 ppm. With a bit-rate tolerance of ±20 ppm for the 
OPUk clock, the client signal's bit-rate tolerance can be ±45 ppm. 

The OPUk overhead for these mappings consists of a Payload Structure Identifier (PSI) including 
the Payload Type (PTl and 255 bytes reserved for future international standardisation (RES) , three | 
Justification Control (JC) bytes, one Negative Justification Opportunity (NJO) byte, and three bytes 
reserved for fiiture international standardization (RES). The JC bytes consist of two bits for 
justification control and six bits reserved for future international standardization. 

The OPUk payload for these mappings consists of 4 x 3808 bytes, including one Positive 
Justification Opportunity (PJO) byte. 
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FIGURE 17-1/G.709 

OPUk frame structure for the mapping of a CBR2G5, CBR10G or CBR40G signal 



The Justification Control (JC) signal, which is located in rows 1, 2 and 3 of column 16, bits 7 and 8, 
is used to control the two justification opportunity bytes NJO and PJO that follow in row 4. 
The asynchronous and bit synchronous mapping processes generate the JC, NJO and PJO according 
to Table 17-1 and Table 17-2, respectively. The demapping process interprets JC, NJO and PJO 
according to Table 17-3. Majority vote (two out of three) shall be used to make the justification 
decision in the demapping process to protect against an error in one of the three JC signals. 



TABLE 17-1/G.709 
JC, NJO and PJO generation by asynchronous mapping process 



JC 


NJO 


PJO 


[7,8] 






00 


justification byte 


data byte 


01 


data byte 


data byte 


10 


not generated 


11 


justification byte 


justification byte j 
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TABLE 17-2/G.709 
JC, NJO and PJO generation by bit synchronous mapping process 



JC 
[7,8] 


NJO 


PJO 


00 


justification byte 


data byte 


01 


not generated 


10 


11 


TABLE 17-3/G.709 
JC, NJO and PJO interpretation 


JC 
[7,8] 


NJO 


PJO 


00 


justification byte 


data byte 


01 


data byte 


data byte 


10 (Note) 


justification byte 


data byte 


11 


justification byte 


justification byte 


Note - A mapper circuit does not generate this code. Due to bit 
errors a demapper circuit might receive this code. 



The value contained in NJO and PJO when they are used as justification bytes is all-Os. The receiver 
is required to ignore the value contained in these bytes whenever they are used as justification 
bytes. 

During a signal fail condition of the incoming CBR2G5, CBR10G or CBR40G client signal (e.g. in 
the case of a loss of input signal), this failed incoming signal is replaced by the generic-AIS signal 
as specified in 16.6.1, and is then mapped into the OPUk. 

During signal fail condition of the incoming ODUk/OPUk signal (e.g. in the case of an ODUk-AIS, 
ODUk-LCK, ODUk-OCI condition) the generic-AIS pattern as specified in 16.6.1 is generated as a 
replacement signal for the lost CBR2G5, CBR10G or CBR40G signal. 

Asynchronous mapping 

The OPUk signal for the asynchronous mapping is created from a locally generated clock (within 
the limits specified in Table 17-3), which is independent of the CBR2G5, CBR10G or CBR40G 
(i.e. 4 {kA) * 2 488 320 kbit/s (k=l,2,3)) client signal. 

The CBR2G5, CBR10G, CBR40G (i.e. 4 (1M) * 2 488 320 kbit/s (k=l,2,3)) signal is mapped into the 
OPUk using a positive/negative/zero (pnz) justification scheme. 

Bit synchronous mapping 

The OPUk clock for the bit synchronous mapping is derived from the CBR2G5, CBR10G or 
CBR40G (i.e. 4 (k " l) * 2 488 320 kbit/s (k=l,2,3)) client signal. During signal fail conditions of the 
incoming CBR2G5, CBR10G or CBR40G signal (e.g. in the case of loss of input signal), the OPUk 
payload signal bit rate shall be within the limits specified in Table 17-3 and neither a frequency nor 
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frame phase discontinuity shall be introduced. The resynchronization on the incoming CBR2G5, 
CBR10G or CBR40G signal shall be done without introducing a frequency or frame phase 
discontinuity. 

The CBR2G5, CBR10G or CBR40G (i.e. 4 (k l) * 2 488 320 kbit/s (k=l,2,3)) signal is mapped into 
the OPUk without using the justification capability within the OPUk frame: NJO contains a 
justification byte, PJO contains a data byte, and the JC signal is fixed to 00. 

17.1.1 Mapping a CBR2G5 signal (e.g. STM-16) into OPU1 

Groups of 8 successive bits (not necessarily being a byte) of the CBR2G5 signal are mapped into a 
Data (D) byte of the OPU1 (Figure 17-2). Once per OPU1 frame, it is possible to perform either a 
positive or a negative justification action. 
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FIGURE 17-2/G.709 
Mapping of a CBR2G5 signal into OPU1 



17.1.2 Mapping a CBR10G signal (e.g. STM-64) into OPU2 

Groups of 8 successive bits (not necessarily being a byte) of the CBR10G signal are mapped into a 
Data (D) byte of the OPU2. 64 Fixed Stuff (FS) bytes are added in columns 1905 to 1920. Once per 
OPU2 frame, it is possible to perform either a positive or a negative justification action. 
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FIGURE 17-3/G.709 
Mapping of a CBR10G signal into OPU2 



17.13 Mapping a CBR40G signal (e.g. STM-256) into OPU3 

Groups of 8 successive bits (not necessarily being a byte) of the CBR40G signal are mapped into a 
Data (D) byte of the OPU3 (Figure 17-4). 128 Fixed Stuff (FS) bytes are added in columns 1265 to 
1280 and 2545 to 2560. Once per OPU3 frame, it is possible to perform either a positive or a 
negative justification action. 
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FIGURE 17-4/G.709 
Mapping of a CBR40G signal into OPU3 



1 7.2 Mapping of ATM cell stream into OPUk 

A constant bit rate ATM cell stream with a capacity that is identical to the OPUk payload area is 
created by multiplexing the ATM cells of a set of ATM VP signals. Rate adaptation is performed as 
part of this cell stream creation process by either inserting idle cells or by discarding cells. Refer to 
1.432.1. The ATM cell stream is mapped into the OPUk payload area with the ATM cell byte 
structure aligned to the ODUk payload byte structure (Figure 17-5). The ATM cell boundaries are 
thus aligned with the OPUk payload byte boundaries. Since the OPUk payload capacity 
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(15232 bytes) is not an integer multiple of the cell length (53 bytes), a cell may cross an OPUk 
frame boundary. 

The ATM cell information field (48 bytes) shall be scrambled before mapping into the OPUk. In the 
reverse operation, following termination of the OPUk signal, the ATM cell information field will be 
descrambled before being passed to the ATM layer. A self-synchronizing scrambler with generator 
polynomial x 43 + 1 shall be used (as specified in Recommendation 1.432.1). The scrambler operates 
for the duration of the cell information field. During the 5-byte header the scrambler operation is 
suspended and the scrambler state retained. The first cell transmitted on start-up will be corrupted 
because the descrambler at the receiving end will not be synchronized to the transmitter scrambler. 
Cell information field scrambling is required to provide security against false cell delineation and 
cell information field replicating the OTUk and ODUk frame alignment signal. 
When extracting the ATM cell stream from the OPUk payload area after the ODUk termination, the 
ATM cells must be recovered. The ATM cell header contains a Header Error Control (HEC) field, 
which may be used in a similar way to a frame alignment word to achieve cell delineation. This 
HEC method uses the correlation between the header bits to be protected by the HEC (32 bits) and 
the control bit of the HEC (8 bits) introduced in the header after computation with a shortened 
cyclic code with generating polynomial g(x)=x? + x 2 + x + 1. 

The remainder from this polynomial is then added to the fixed pattern "01010101" in order to 
improve the cell delineation performance. This method is similar to conventional frame alignment 
recovery where the alignment signal is not fixed but varies from cell to cell. 
More information on HEC cell delineation is given in Recommendation 1.432.1 
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FIGURE 17-5/G.709 
OPUk frame structure and mapping of ATM cells into OPUk 



The OPUk overhead for the ATM mapping consists of a Payload Structure Identifier (PSI) 
including the Payload Type (PT) and 255 bytes reserved for future international sta ndardisation 
(RES), and seven bytes reserved for future international standardization (RES). 

The OPUk payload for the ATM mapping consists of 4 x 3808 bytes. 
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17.3 Mapping of GFP frames into OPUk 

The mapping of Generic Framing Procedure (GFP) frames is performed by aligning the byte 
structure of every GFP frame with the byte structure of the OPUk Payload (Figure 17-6). Since the 
GFP frames are of variable length (the mapping does not impose any restrictions on the maximum 
frame length), a frame may cross the OPUk frame boundary. 

GFP frames arrive as a continuous bit stream with a capacity that is identical to the OPUk payload 
area, due to the insertion of Idle frames at the GFP encapsulation stage. The GFP frame stream is 
scrambled during encapsulation. 

NOTE - There is no rate adaptation or scrambling required at the mapping stage; this is performed 
by the GFP encapsulation process. 
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FIGURE 17-6/G.709 
OPUk frame structure and mapping of GFP frames into OPUk 



The OPUk overhead for the GFP mapping consists of a Payload Structure Identifier (PSI) including 
the Payload Type (PT 1 and 255 bytes reserved for future international standardisation (RES), and 
seven bytes reserved for future international standardization (RES). 

The OPUk payload for the GFP mapping consists of 4 x 3808 bytes. 

17.4 Mapping of test signal into OPUk 
17.4.1 Mapping of a NULL client into OPUk 

An OPUk payload signal with an all-O's pattern (Figure 17-7) is defined for test purposes. This is 
referred to as the NULL client. 
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FIGURE 17-7/G.709 
OPUk frame structure and mapping of NULL client into OPUk 



The OPUk overhead for the NULL mapping consists of a Payload Structure Identifier (PSI) 
including the Payload Type (VP and 255 bvtes reserved for future internationa l standardisation 
(RES), and seven bytes reserved for future international standardization (RES). 

The OPUk payload for the NULL mapping consists of 4 x 3808 bytes. 
17.4.2 Mapping of PRBS test signal into OPUk 

For test purposes a 2 147 483 647-bit pseudo-random test sequence (2 31 -1) as specified in 5.8/O.150 
can be mapped into the OPUk Payload. Groups of 8 successive bits of the 2 147 483 647-bit 
pseudo-random test sequence signal are mapped into 8 Data bits (8D) (i.e. one byte) of the ODU3 
Payload (Figure 17-8). 
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FIGURE 17-8/G.709 

OPUk frame structure and mapping of 2 147 483 647-bit 
pseudo-random test sequence into OPUk 



The OPUk overhead for the PRBS mapping consists of a Payload Structure Identifier (PSI) 
including the Payload Type (PT) and 255 bytes reserved for future international standardisation 
(RES), and seven bytes reserved for future international standardization (RES). 

The OPUk payload for the PRBS mapping consists of 4 x 3808 bytes. 
17.5 Mapping of a non-specific client bit stream into OPUk 

In addition to the mappings of specific client signals as specified in the other subclauses of this 
clause, a non-specific client mapping into OPUk is specified. Any (set of) client signal(s), which 
after encapsulation into a continuous bit stream with a bit rate of the OPUk Payload, can be mapped 
into the OPUk Payload (Figure 17-9). The bit stream must be synchronous with the OPUk signal. 
Any justification must be included in the continuous bit stream creation process. The continuous bit 
stream must be scrambled before mapping into the OPUk Payload. 



ITU-T G.709 (10/2001) - Editor's version 



85 



\X!olumn 
Row X 15 16 17 18_ 



3824 



CS 


CS 


cs 
cs 


cs 


cs 


PSI 


cs 



OPUkOH 



0 



PSI 



255 



RES 



OPUk Payload (4 x 3808 bytes) 



T154285WX) 
(114739) 



FIGURE 17-9/G.709 
OPUk frame structure for the mapping of a synchronous constant bit stream 

The OPUk overhead for the mapping consists of a Payload Structure Identifier (PSI) including the 
Payload Type (V Ti and 255 bvtes reserved for future international standardisation (RES), and seven | 
bytes for client specific purposes (CS). The definition of these CS overhead bytes is performed 
within the encapsulation process specification. 

The OPUk payload for this non-specific mapping consists of 4 x 3808 bytes. 

17.5.1 Mapping bit stream with octet timing into OPUk 

If octet timing is available, each octet of the incoming data stream will be mapped into a data byte 
(octet) of the OPUk payload. 

17.5.2 Mapping bit stream without octet timing into OPUk 

If octet timing is not available, groups of 8 successive bits (not necessarily an octet) of the incoming 
data stream will be mapped into a data byte (octet) of the OPUk payload. 

17.6 Mapping of other constant bit-rate signals with justification into OPUk 

For farther study. 



18 Concatenation 

Concatenation in the OTN is realised by means of virtual concatenation of OPUk signals 
18.1 Virtual Concatenation of OPUk 

18.1.1 Virtual Concatenated OPUk (OPUk-Xv, k = 1 .. 3, X = 1 .. 256) 

The OPUk-Xv (k=l,2,3) frame structure is shown in Figure 18-1. It is organised in an octet based 
block frame structure with 4 rows and X x 3810 columns. 
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The two main areas of the OPUk-Xv frame are: 

• OPUk-Xv Overhead area; 

• OPUk-Xv Payload area. 

Columns 14X+1 to 16X of the OPUk-Xv are dedicated to OPUk-Xv Overhead area. 

Columns 16X+1 to 3824X of the OPUk-Xv are dedicated to OPUk-Xv Payload area. 

NOTE - OPUk-Xv column numbers are derived from the OPUk columns in the ODUk frame. 

A OPUk-Xv provides a contiguous payload area of X OPUk payload areas (OPUk-X-PLD) with a 
payload capacity of X * 238/(239-k) * 4 (k " l) * 2 488 320 kbit/s ± 20 ppm as shown in Figure 18-1. 
The OPUk-X-PLD is mapped in X individual OPUks which form the OPUk-Xv. 

Each OPUk in the OPUk-Xv is transported in an ODUk and the X ODUks form the ODUk-Xv. 

Each ODUk of the ODUk-Xv is transported individually through the network. Due to different 
propagation delay of the ODUks a differential delay will occur between the individual ODUks and 
thus OPUks. This differential delay has to be compensated and the individual OPUks have to be 
realigned for access to the contiguous payload area. 
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18.1.2 OPUk-Xv OH description 
18.1.2.1 OPUk-Xv OH location 

The OPUk-Xv overhead consists of: X times a Payload Structure Identifier (PSI) including the 
Payload Type (PT), X times virtual concatenation (VCOH) overhead used for a virtual 
concatenation specific sequence and multiframe indication, and overhead (e.g. justification control 
and opportunity bits) associated with the mapping of client signals into the OPUk payload as shown 
in Figure 18-1. The PSI and VCOH overhead is specific for each individual OPUk of the OPUk-Xv, 
while the mapping specific overhead is related to the concatenated signal 
The OPUk-Xv VCOH consists of a 3-byte VCOH per OPUk. The VCOH bytes in each OPUk are 
used as defined below. 
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Figure 18-2/G.709 - OPUk-Xv Virtual Concatenation Overhead 
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18.1.2.2 OPUk-Xv OH defintion 

18.1.2.2.1 OPUk-Xv Payload Structure Identifier (PSI) 

In each OPUk of the OPUk-Xv one byte is allocated in row 4, column 15 (Figure 18-2) to transport 
a 256-byte Payload Structure Identifier (PSI) signal as defined in 15.9.2. 

PSI[l]is used for a virtual concatenation specific payload type identifier (vcPT). 

The PSI content is identical for each OPUk of the OPUk-Xv. 

18.1.2.2.1.1 OPUk-Xv Payload Type (vcPT) 

A one byte OPUk-Xv Payload Type signal is defined in the PSI[1] byte of the Payload Structure 
Identifier to indicate the composition of the OPUk-Xv signal. The code points are defined in Table 
18-1. 



TABLE 18-1/G.709 

Payload Type (vcPT) code points for virtual concatenated OPUk (OPUk-Xv) signals 



MSB 
1234 


LSB 
5678 


Hex code 
(NOTE 1) 


Interpretation 


0000 | 


0001 


01 


Experimental mapping (NOTE 3) 


0000 


00 1 0 


02 


asynchronous CBR mapping, see 18.2.1, 18.2.2 


0000 


0011 


03 


bit synchronous CBR mapping, see 18.2.1, 18.2.2 


0000 


0100 


04 


ATM mapping, see 18.2.3 


0000 


0101 


05 


GFP mapping, see 18.2.4 


0001 


0000 


10 


bit stream with octet timing mapping, see 18.2.6 


000 1 


0001 


11 


bit stream without octet timing mapping, see 1 8.2.6 


0 101 


0101 


55 


Not available (NOTE 2) 


0 110 


0110 


66 


Not available (NOTE 2) 


1000 


xxxx 


80-8F 


reserved codes for proprietary use (NOTE 4) 


1111 


1101 


FD 


NULL test signal mapping, see 18.2.5.1 


1111 


1110 


FE 


PRBS test signal mapping, see 18.2.5.2 


1111 


1111 


FF 


Not available (NOTE 2) ! 


NOTE 1 - There are 228 spare codes left for future international standardisation. 

NOTE 2 - These values are excluded from the set of available code points. These bit patterns are 

present in ODUk maintenance signals. 

NOTE 3 - Value "01" is only to be used in cases where a mapping code is not defined in the above 
table. By using this code, the development (experimental) activities do not impact the OTN network. 
There is no forward compatibility if a specific payload type is assigned later. If a new code is 
assigned, equipment using this code shall be reconfigured to use the new code. 

NOTE 4 - These 16 code values will not be subject to standardization. 
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18.1.2.2.1.2 OPUk-Xv Payload Structure Identifier Reserved overhead (RES) 

254 bytes are reserved in the OPUk PSI for future international standardization. These bytes are 
located in PSI[2] to [PSI255] of the OPUk overhead. These bytes are set to all ZEROs. 

18.1.2.2.2 OPUk-Xv Virtual Concatenation Overhead (VCOH1/2/3) 

Three bytes per individual OPUk of the OPUk-Xv are used to transport a 8x3 byte x 32 frame 
structure for virtual concatenation specific overhead. These bytes are located in rows 1 , 2 and 3 of 
column 15 as shown in figure 18-2. 

The structure is aligned with the ODUk multiframe and locked to bits 4, 5, 6, 7 and 8 of the MFAS. 

The structure is repeated 8 times in the 256 frame multiframe. 

The structure is used to transport multiframe, sequences an LCAS control overhead. 

18.1.2.2.2.1 OPUk-Xv Virtual Concatenation MultiFrame Indicator (MFI1, MFI2) 

A two-stage multiframe is introduced to cover differential delay measurement (between the member 
signals within the virtual concatenated group) and compensation (of those differential delays) by the 
realignment process within the receiver. 

The first stage uses MFAS in the Frame Alignment overhead area for the 8-bit multiframe indicator. 
MFAS is incremented every ODUk frame and counts from 0 to 255. 
The second stage uses the MFI1 and MFI2 overhead bytes in the VCOH. They form a 16 bit 
multiframe counter with the MSBs in MFI1 and the LSBs in MFI2. 

MFI1 is located in VCOH1[0] and MFI2 in VCOHl[l]. 

The multiframe counter of the second stage counts from 0 to 65535 and is incremented at the start 
of each multiframe of the first stage (MFAS=0). 

The resulting overall multiframe (a combination of 1 st multi-frame and 2 nd multi-frame counter) is 
16 777 216 ODUk frames long. 

At the start of the OPUk-Xv the multiframe sequence of all individual OPUks of the OPUk-Xv is 
identical. 

The realignment process has to be able to compensate a differential delay of at least 125 us. 

18.1.2.2.2.2 OPUk-Xv Sequence Indicator (SQ) 

The sequence indicator SQ identifies the sequence/order in which the individual OPUks of the 
OPUk-Xv are combined to form the contiguous OPUk-X-PLD as shown in Figure 18-1. 
The 8-bit sequence number SQ (which supports values of X up to 256) is transported in VCOHl[4]. 
Bit 1 of VCOH1 [4] is the MSB, bit 8 is the LSB. 

Each OPUk of an OPUk-Xv has a fixed unique sequence number in the range of 0 to (X-l). The 
OPUk transporting the first time slot of the OPUk-Xv has the sequence number 0, the OPUk 
transporting the second time slot the sequence number 1 and so on up to the OPUk transporting 
time slot X of the OPUk-Xv with the sequence number (X-l). 

For applications requiring fixed bandwidth the sequence number is fixed assigned and not 
configurable. This allows the constitution of the OPUk-Xv either to be checked without usmg the 
trace, or to be transported via a number of ODUk signals which have their trail termination 
functions being part of an ODUk trail termination function resource group. 

Refer to G.7042 for the use and operation. 
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18.1.2.2.2.3 OPUk-Xv LCAS Control Words (CTRL) 

The LCAS control word (CTRL) is located in bits 1 to 4 of VCOHl[5]. Bit 1 of VCOHl[5] is the 
MSB, bit 4 is the LSB. 

Refer to G.7042 for the LCAS control commands, their coding and operation. 

18.1.2.2.2.3 OPUk-Xv LCAS Member Status Field (MST) 

The LCA member status field (MST) reports the status of the individual OPUks of the OPUk-Xv. 

One bit is used per OPUk to report the status from sink to source. VCOH2[0] to VCOH2[31] are 
used as shown in Figure 18-2. Refer to G.7042 for coding and operation. 

The status of all members (256) is transferred in 1567 fis (k=l), 390 [is (k=2) and 97 \is (k=3). 

18.1.2.2.2.4 OPUk-Xv LCAS Group Identification (GID) 

The LCAS Group Identification (GID) provides the receiver with a means of verifying that all the 
arriving channels originated from one transmitter. Refer to G.7042 for coding and operation. 

Bit 5 of VCOHl[5] is used for the GID. 

18.1.2.2.2.5 OPUk-Xv LCAS Re-Sequence Acknowledge (RS-Ack) 

Re-Sequence Acknowledge, an indication from sink to source that a re-sequence, a sequence 
increase or a sequence decrease has been detected. Refer to G.7042 for coding and operation. 

Bit 6 of VCOHl[5] is used for the RS-Ack. 

18.1.2.2.2.6 OPUk-Xv LCAS Cyclic Redundancy Check (CRC) 

A 8-bit CRC check for fast acceptance of VirtConc LCAS OH is provided. The CRC-8 is calculated 
over VCOH1 and VCOH2 on a frame per frame based and inserted into VCOH3. The CRC_8 
Polynomial is x? + x 2 + x + 1. Refer to G.7042 for operation. 

18.1.2.2.2.7 OPUk-Xv VCOH Reserved Overhead 
The reserved VCOH is set to all-Os. 

18.1.2.2.3 OPUk Mapping Specific Overhead 

X times four bytes are reserved in the OPUk overhead for mapping specific overhead. These bytes 
are located in columns 15X+1 to 16X. 

The use of these bytes depends on the specific client signal mapping (defined in 18.2). 
18.2 Mapping of client signals 

18.2.1 Mapping of CBR signals (e.g. STM-64/256) into OPUk-4v 

Mapping of a CBR signal (with up to ±20 ppm bit-rate tolerance) into an OPUk-4v may be 
performed according two different modes (asynchronous and bit synchronous) based on one generic 
OPUk-4v frame structure (Figure 18-3). 

NOTE 1 - Examples of such signals are STM-64 and STM-256. 

NOTE 2 - The maximum bit-rate tolerance between OPUk-4v and the client signal clock, which can 
be accommodated by this mapping scheme, is ±65 ppm. With a bit-rate tolerance of ±20 ppm for 
the OPUk-4v clock, the client signal's bit-rate tolerance can be ±45 ppm. 
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The OPUk-4v overhead for these mappings consists of a X (X=4) times a Payload Structure 
Identifier (PSI), which includes the Payload Type (PT) and virtual concatenation payload type 
(vcPT), X times Virtual Concatenation Overhead (VCOH), three Justification Control (JC) bytes 
and one Negative Justification Opportunity (NJO) byte per row. The JC bytes consist of two bits for 
justification control and six bits reserved for future international standardization. 
The OPUk-4v payload for these mappings consists of X (X=4) times 4 x 3808 bytes, including one 
Positive Justification Opportunity (PJO) byte per row. 



Column ,_ cn co -r- cm co 

' a & i s & £ 

Row- * * * " 



r- CM CO 

x S a £ g s 

m «- <o to to 



I 

CO 



PSI 



PSI 



PSI 



PSI 



JC 



JC 



JC 



JC 



JC 



JC 



JC 



JC 



JC 



JC 



NJO PJO 



NJO PJO 



NJO PJO 



NJO PJO 



PSI 



0 


PT (06) 


1 


vcPT 


■l 


RES 


255 





OPUk-4vOH 



X=4 



OPUk-4v Payload (4 x X x 3808 bytes) 
1 2 3 4 5 6 7 8 



Reserved 



JC 



FIGURE 18-3/G.709 
OPUk-4v frame structure for the mapping of a CBR10G or CBR40G signal 



The Justification Control (JC) signals, which are located in columns 15X+1 (61), 15X+2 (62) and 
15X+3 (63) of each row, bits 7 and 8, are used to control the two justification opportunity fields 
NJO and PJO that follow in column 16X (64) and 16X+1 (65) of each row. 

The asynchronous and bit synchronous mapping processes generate the JC, NJO and PJO according 

to Table 17-1 and Table 17-2, respectively. The demapping process interprets JC, NJO and PJO 

according to Table 17-3. Majority vote (two out of three) shall be used to make the justification 

decision in the demapping process to protect against an error in one of the three JC signals. 

The value contained in NJO and PJO when they are used as justification bytes is all-Os. The receiver 

is required to ignore the value contained in these bytes whenever they are used as justification 

bytes. 

During a signal fail condition of the incoming CBR client signal (e.g. in the case of a loss of input 
signal), this failed incoming signal is replaced by the generic-AIS signal as specified in 16.6.1, and 
is then mapped into the OPUk-4v. 

During signal fail condition of the incoming ODUk/OPUk-4v signal (e.g. in the case of an ODUk- 
AIS, ODUk-LCK, ODUk-OCI condition) the generic-AIS pattern as specified in 16.6.1 is generated 
as a replacement signal for the lost CBR signal. 

Asynchronous mapping 

The OPUk-4v signal for the asynchronous mapping is created from a locally generated clock 
(within the limits specified in Table 7-3), which is independent of the CBR (i.e. 4 ( + * 2 488 320 
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kbit/s) client signal. 

The CBR (i.e. 4 (k+1) * 2 488 320 kbit/s) signal is mapped into the OPUk-4v using a 
positive/negative/zero (pnz) justification scheme. 

Bit synchronous mapping 

The OPUk-4v clock for the bit synchronous mapping is derived from the CBR (i.e. 4 (k+l) * 2 488 
320 kbit/s) client signal. During signal fail conditions of the incoming CBR signal (e.g. in the case 
of loss of input signal), the OPUk-4v payload signal bit rate shall be within the limits specified in 
Table 7-3 and neither a frequency nor frame phase discontinuity shall be introduced. The 
resynchronization on the incoming CBR signal shall be done without introducing a frequency or 
frame phase discontinuity. 

The CBR (i.e. 4 (k+1) * 2 488 320 kbit/s) signal is mapped into the OPUk-4v without using the 
justification capability within the OPUk-Xv frame: NJO contains four justification bytes, PJO 
contains four data bytes, and the JC signal is fixed to 00. 

18.2.1.1 Mapping a CBR10G signal (e.g. STM-64) into OPUl-4v 

Groups of 8 successive bits (not necessarily being a byte) of the CBR10G signal are mapped into a 
Data (D) byte of the OPUl-4v (Figure 18-4). Once per OPUl-4v row (and thus four times per 
OPUl-4v frame), it is possible to perform either a positive or a negative justification action. 
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FIGURE 18-4/G.709 
Mapping of a CBR10G signal into OPUl-4v 



18.2.1.2 Mapping a CBR40G signal (e.g. STM-256) into OPU2-4v 

Groups of 8 successive bits (not necessarily being a byte) of the CBR40G signal are mapped into a 
Data (D) byte of the OPU2-4v (Figure 18-5). X times 64 Fixed Stuff (FS) bytes are added in 
columns 1904X+1 to 1920X. Once per OPU2-Xv row (and thus four times per OPU2-4v frame), it 
is possible to perform either a positive or a negative justification action. 
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FIGURE 18-5/G.709 
Mapping of a CBR40G signal into OPU2-4v 



18.2.2 Mapping of CBR signals (e.g. STM-256) into OPUk-16v 

Mapping of a CBR signal (with up to ±20 ppm bit-rate tolerance) into an OPUk-16v may be 
performed according two different modes (asynchronous and bit synchronous) based on one generic 
modified OPUk-16v frame structure (Figure 18-6). This modified OPUk-16v frame structure has 
part of its OPUk-16v OH distributed over the frame; consequently, columns 15X+5 to 16X are now 
within the OPUk- 1 6v payload area. 

NOTE 1 - Examples of such signals are STM-256. 

NOTE 2 - The maximum bit-rate tolerance between OPUk-16v and the client signal clock, which 
can be accommodated by this mapping scheme, is ±65 ppm. With a bit-rate tolerance of ±20 ppm 
for the OPUk-16v clock, the client signal's bit-rate tolerance can be ±45 ppm. 

The OPUk-16v overhead for these mappings consists of a X (X=16) times a Payload Structure 
Identifier (PSI), which includes the Payload Type (PT) and virtual concatenation payload type 
(vcPT), X times Virtual Concatenation Overhead (VCOH), 4x3 Justification Control (JC) bytes and 
4x1 Negative Justification Opportunity (NJO) bytes per row. The JC bytes consist of two bits for 
justification control and six bits reserved for future international standardization. 

The OPUk-16v payload for these mappings consists of 4 blocks of 4 x 15232 bytes, including 4x1 
Positive Justification Opportunity (PJO) bytes per row. 
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FIGURE 18-6/G.709 
OPUk-16v frame structure for the mapping of a CBR signal 

The Justification Control (JC) signals, which are located in the locations indicated in Figure 18-3, 
bits 7 and 8, are used to control the two justification opportunity fields NJO and PJO that follow in 
the next two columns of each row. 

The asynchronous and bit synchronous mapping processes generate the JC, NJO and PJO according 
to Table 17-1 and Table 17-2, respectively. The demapping process interprets JC, NJO and PJO 
according to Table 17-3. Majority vote (two out of three) shall be used to make the justification 
decision in the demapping process to protect against an error in one of the three JC signals. 

The value contained in NJO and PJO when they are used as justification bytes is all-Os. The receiver 
is required to ignore the value contained in these bytes whenever they are used as justification 
bytes. 

During a signal fail condition of the incoming CBR client signal (e.g. in the case of a loss of input 
signal), this failed incoming signal is replaced by the generic-AIS signal as specified in 16.6.1, and 
is then mapped into the OPUk-16v. 

During signal fail condition of the incoming ODUk/OPUk-16v signal (e.g. in the case of an ODUk- 
AIS, ODUk-LCK, ODUk-OCI condition) the generic-AIS pattern as specified in 16.6.1 is generated 
as a replacement signal for the lost CBR signal. 

Asynchronous mapping 

The OPUk-16v signal for the asynchronous mapping is created from a locally generated clock 
(within the limits specified in Table 7-3), which is independent of the CBR (i.e. 4 (k+2) * 2 488 320 
kbit/s) client signal. 

The CBR (i.e. 4 (k+2) * 2 488 320 kbit/s) signal is mapped into the OPUk-16v using a 
positive/negative/zero (pnz) justification scheme. 

Bit synchronous mapping 

The OPUk-16v clock for the bit synchronous mapping is derived from the CBR client signal. 
During signal fail conditions of the incoming CBR signal (e.g. in the case of loss of input signal), 
the OPUk-16v payload signal bit rate shall be within the limits specified in Table 7-3 and neither a 
frequency nor frame phase discontinuity shall be introduced. The resynchronization on the 



ITU-T G.709 (10/2001) - Editor's version 



95 



incoming CBR signal shall be done without introducing a frequency or frame phase discontinuity. 

The CBR (i.e. 4 (k+2) * 2 488 320 kbit/s) signal is mapped into the OPUk-16v without using the 
justification capability within the OPUk-16v frame: NJO contains four justification bytes, P JO 
contains four data bytes, and the JC signal is fixed to 00. 

18.2.2.1 Mapping a CBR40G signal (e.g. STM-256) into OPUl-16v 

Groups of 8 successive bits (not necessarily being a byte) of the CBR40G signal are mapped into a 
Data (D) byte of the OPUl-16v (Figure 18-7). Four times per OPUl-16v row (and thus sixteen 
times per OPUl-16v frame), it is possible to perform either a positive or a negative justification 
action. 
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FIGURE 18-7/G.709 
Mapping of a CBR40G signal into OPUl-16v 



18.23 Mapping of ATM cell stream into OPUk-Xv 

A constant bit rate ATM cell stream with a capacity that is identical to the OPUk-Xv payload area is 
created by multiplexing the ATM cells of a set of ATM VP signals. Rate adaptation is performed as 
part of this cell stream creation process by either inserting idle cells or by discarding cells. Refer to 
1.432.1. The ATM cell stream is mapped into the OPUk-Xv payload area with the ATM cell byte 
structure aligned to the OPUk-Xv payload byte structure (Figure 18-8). The ATM cell boundaries 
are thus aligned with the OPUk-Xv payload byte boundaries. Since the OPUk-Xv payload capacity 
(X x 15232 bytes) is not an integer multiple of the cell length (53 bytes), a cell may cross an OPUk- 
Xv frame boundary. 

The ATM cell information field (48 bytes) shall be scrambled before mapping into the OPUk-Xv. 
In the reverse operation, following termination of the OPUk-Xv signal, the ATM cell information 
field will be descrambled before being passed to the ATM layer. A self-synchronizing scrambler 
with generator polynomial x 43 + 1 shall be used (as specified in Recommendation 1.432.1). The 
scrambler operates for the duration of the cell information field. During the 5-byte header the 
scrambler operation is suspended and the scrambler state retained. The first cell transmitted on start- 
up will be corrupted because the descrambler at the receiving end will not be synchronized to the 
transmitter scrambler. Cell information field scrambling is required to provide security against false 
cell delineation and cell information field replicating the OTUk and ODUk frame alignment signal. 

When extracting the ATM cell stream from the OPUk-Xv payload area after the ODUk 
terminations, the ATM cells must be recovered. The ATM cell header contains a Header Error 
Control (HEC) field, which may be used in a similar way to a frame alignment word to achieve cell 
delineation. This HEC method uses the correlation between the header bits to be protected by the 
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HEC (32 bits) and the control bit of the HEC (8 bits) introduced in the header after computation 
with a shortened cyclic code with generating polynomial g(x)=x? + x 2 + x + 1. 

The remainder from this polynomial is then added to the fixed pattern "01010101" in order to 
improve the cell delineation performance. This method is similar to conventional frame alignment 
recovery where the alignment signal is not fixed but varies from cell to cell. 

More information on HEC cell delineation is given in Recommendation 1.432.1. 
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FIGURE 18-8/G.709 
OPUk-Xv frame structure and mapping of ATM cells into OPUk-Xv 



The OPUk-Xv overhead for the ATM mapping consists of X times a Payload Structure Identifier 
(PSI), which includes the Payload Type (PT) and virtual concatenation payload type (vcPT), X 
times three Virtual Concatenation Overhead (VCOH) bytes and X times four bytes reserved for 
future international standardization (RES). 

The OPUk-Xv payload for the ATM mapping consists of 4X x 3808 bytes. 
18.2.4 Mapping of GFP frames into OPUk-Xv 

The mapping of Generic Framing Procedure (GFP) frames is performed by aligning the byte 
structure of every GFP frame with the byte structure of the OPUk-Xv Payload (Figure 18-9). Since 
the GFP frames are of variable length (the mapping does not impose any restrictions on the 
maximum frame length), a GFP frame may cross the OPUk frame boundary. A GFP frame consists 
of a GFP header and a GFP payload area. 

GFP frames arrive as a continuous bit stream with a capacity that is identical to the OPUk-Xv 
payload area, due to the insertion of GFP Idles at the GFP encapsulation stage. The GFP frame 
stream is scrambled during encapsulation. 

NOTE - There is no rate adaptation or scrambling required at the mapping stage; this is performed 
by the GFP encapsulation process. 
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FIGURE 18-9/G.709 
OPUk-Xv frame structure and mapping of GFP frames into OPUk-Xv 

The OPUk-Xv overhead for the GFP mapping consists of X times a Payload Structure Identifier 
(PSI), which includes the Payload Type (PT) and virtual concatenation payload type (vcPT), X 
times three Virtual Concatenation Overhead (VCOH) bytes and X times four bytes reserved for 
future international standardization (RES). 

The OPUk-Xv payload for the GFP mapping consists of 4X x 3808 bytes. 
18.2.5 Mapping of test signal into OPUk-Xv 
18.2.5.1 Mapping of a NULL client into OPUk-Xv 

An OPUk-Xv payload signal with an all-0's pattern (Figure 18-10) is defined for test purposes. This 
is referred to as the NULL client. 
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FIGURE 18-10/G.709 
OPUk-Xv frame structure and mapping of NULL client into OPUk-Xv 

The OPUk-Xv overhead for the NULL mapping consists of X times a Payload Structure Identifier 
(PSI), which includes the Payload Type (PT) and virtual concatenation payload type (vcPT), X 
times three Virtual Concatenation Overhead (VCOH) bytes and X times four bytes reserved for 
future international standardization (RES). 

The OPUk-Xv payload for the NULL mapping consists of 4X x 3808 bytes. 
18.2.5.2 Mapping of PRBS test signal into OPUk-Xv 

For test purposes a 2 147 483 647-bit pseudo-random test sequence (2 31 -1) as specified in 5.8/O.150 
can be mapped into the OPUk-Xv Payload. Groups of 8 successive bits of the 2 147 483 647-bit 
pseudo-random test sequence signal are mapped into 8 Data bits (8D) (i.e. one byte) of the ODU3 
Payload (Figure 18-11). 
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FIGURE 1 8-1 1/G.709 

OPUk-Xv frame structure and mapping of 2 147 483 647-bit 
pseudo-random test sequence into OPUk-Xv 



The OPUk-Xv overhead for the PRBS mapping consists of X times a Payload Structure Identifier 
(PSI), which includes the Payload Type (PT) and virtual concatenation payload type (vcPT), X 
times three Virtual Concatenation Overhead (VCOH) bytes and X times four bytes reserved for 
future international standardization (RES). 

The OPUk-Xv payload for the PRBS mapping consists of 4X x 3808 bytes. 
18.2.6 Mapping of a non-specific client bit stream into OPUk-Xv 

In addition to the mappings of specific client signals as specified in the other subclauses of this 
clause, a non-specific client mapping into OPUk-Xv is specified. Any (set of) client signal(s), 
which after encapsulation into a continuous bit stream with a bit rate of the OPUk-Xv Payload, can 
be mapped into the OPUk-Xv Payload (Figure 18-12). The bit stream must be synchronous with the 
OPUk-Xv signal. Any justification must be included in the continuous bit stream creation process. 
The continuous bit stream must be scrambled before mapping into the OPUk-Xv Payload. 
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FIGURE 18-12/G.709 
OPUk-Xv frame structure for the mapping of a synchronous constant bit stream 

The OPUk-Xv overhead for the mapping consists of X times a Payioad Structure Identifier (PSI), 
which includes the Payioad Type (PT) and virtual concatenation payioad type (vcPT), X times three 
Virtual Concatenation Overhead (VCOH) bytes and X times four bytes for client specific purposes 
(CS). The definition of these CS overhead bytes is performed within the encapsulation process 
specification. 

The OPUk-Xv payioad for this non-specific mapping consists of 4X x 3808 bytes. 

18.2.6.1 Mapping bit stream with octet timing into OPUk-Xv 

If octet timing is available, each octet of the incoming data stream will be mapped into a data byte 
(octet) of the OPUk-Xv payioad. 

18.2.6.2 Mapping bit stream without octet timing into OPUk-Xv 

If octet timing is not available, groups of 8 successive bits (not necessarily an octet) of the incoming 
data stream will be mapped into a data byte (octet) of the OPUk-Xv payioad. 

18.3 LCAS for Virtual concatenation. 

Refer to G.7042. 



19 MAPPING ODUk SIGNALS INTO THE ODTUjk SIGNAL 
19.1 OPUk Tributary Slot definition 

The OPUk is divided in a number of Tributary Slots (TS) and these Tributary Slots are interleaved 
within the OPUk. A Tributary Slot includes a part of the OPUk OH area and a part of the OPUk 
payioad area. The bytes of the ODUj frame are mapped into the OPUk payioad area of the Tributary 
Slot. The bytes of the ODTUjk Justification Overhead are mapped into the OPUk OH area. 
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19.1.1 OPU2 Tributary Slot allocation 

Figure 19-1 presents the OPU2 tributary slot allocation. An OPU2 Tributary Slot occupies 25% of 
the OPU2 Payload area. It is a structure with 952 columns by 4 rows. The four OPU2 TS's are byte 
interleaved in the OPU2 Payload area. 

In addition, the Justification Overhead (JOH) consisting of Justification Control (JC) and Negative 
Justification Opportunity (NJO) signals of the 4 OPU2 TSs are located in the overhead area, column 
16 of rows 1 to 4. The JOH is assigned to the related tributary slots on a per frame base. JOH for a 
tributary slot is available once every 4 frames. A 4-frame multiframe structure is used for this 
assignment. This multiframe structure is locked to bits 7 and 8 of the MFAS byte as shown in Table 
19-1. 

TABLE 19-1/G.709 
OPU2 Justification OH tributary slots 



MFAS bits 


JOH TS 
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FIGURE 19-1/G.709 
OPU2 tributary slot allocation 



19.1.2 OPU3 Tributary Slot allocation 

Figure 19-2 presents the OPU3 tributary slot allocation. An OPU3 Tributary Slot occupies 6.25% of 
the OPU3 Payload area. It is a structure with 238 columns by 4 rows (Figure 19-3). The sixteen 
OPU3 TS's are byte interleaved in the OPU3 Payload area. 

In addition, the Justification Overhead (JOH) consisting of Justification Control (JC) and Negative 
Justification Opportunity (NJO) signals of the 16 OPU3 TSs are located in the overhead area, 
column 16 of rows 1 to 4. The JOH is assigned to the related tributary slots on a per frame base. 
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JOH for a tributary slot is available once every 16 frames. A 16-frame multiframe structure is used 
for this assignment. This multiframe structure is locked to bits 5, 6, 7 and 8 of the MFAS byte as 
shown in Table 19-2. 
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FIGURE 19-2/G.709 
OPU3 tributary si t allocation 
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TABLE 19-2/G.709 
OPU3 Justification OH tributary slots 



MFAS bits 


JOHTS 


5678 




0000 


1 


0001 


2 


0010 


3 


0011 


4 I 


0100 


5 


0101 


6 


0110 


7 


0111 


8 



MFAS bits 


JOHTS 


5678 




1000 


9 


1001 


io ; 


1010 


n 


1011 


12 


1100 


13 


1101 


14 


1110 


15 


1111 


16 



19.2 ODTUjk definition 

19.2.1 ODTU12 

The Optical channel Data Tributary Unit 12 (ODTU12) is a structure with 952 columns by 4 times 
4 rows plus 1 column of Justification Overhead (JOH). It carries a justified ODU1 signal. The 
location of the JOH column depends on the OPU2 tributary slot used when multiplexing the 
ODTU12 in the OPU2 (see 19.1.1). 

19.2.2 ODTU13 

The Optical channel Data Tributary Unit 13 (ODTU13) is a structure with 238 columns by 16 times 
4 rows plus 1 column of Justification Overhead (JOH). It carries a justified ODU1 signal. The 
location of the JOH column depends on the OPU3 tributary slot used when multiplexing the 
ODTU13 in the OPU3 (see 19.1.2). 

19.23 ODTU23 

The Optical channel Data Tributary Unit 23 (ODTU23) is a structure with 952 columns by 16 times 
4 rows plus 4 times 1 column of Justification Overhead (JOH). It carries a justified ODU2 signal. 
The location of the JOH column depends on the OPU3 tributary slot used when multiplexing the 
ODTU23 in the OPU3 (see 19.1.2). They might not be equally distributed. 

19.3 Multiplexing ODTUjk signals into the OPUk 

Multiplexing an ODTU12 signal into an OPU2 is realised by means of the mapping of the ODTU12 
signal in one of the four OPU2 Tributary Slots. 

Multiplexing an ODTU13 signal into an OPU3 is realised by means of the mapping of the ODTU13 
signal in one of the sixteen OPU3 Tributary Slots. 

Multiplexing an ODTU23 signal into an OPU3 is realised by means of the mapping of the ODTU23 
signal in four (of the sixteen) arbitrary OPU3 Tributary Slots: OPU3 TSa, TSb, TSc and TSd with 
l<a<b<c<d<16. 

Note - a, b, c and d do not have to be sequential (a=i, b=i+l, c=i+2, d=i+3); the values can be 
arbitrarily selected to prevent bandwidth fragmentation. 
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The OPUk overhead for these multiplexed signals consists of a Payload Structure Identifier (PSI), 
which includes the Payload Type (PT) and the Multiplex Structure Identifier (MSI), three 
Justification Control (JC) bytes, one Negative Justification Opportunity (NJO) byte, and three bytes 
reserved for future international standardisation (RES). The JC bytes consist of two bits for 
justification control and six bits reserved for future international standardisation. 
The 3-bytes Justification Control (JC) signal, which is located in rows/columns/frames indicated in 
Figures 19-1 and 19-2, is used to control the three justification opportunity bytes NJO, PJOl and 
PJ02 that follow in row 4. 

19.3.1 ODTU12 mapping into one 0PU2 Tributary Slot 

A byte of the ODTU12 signal is mapped into a byte of an OPU2 TS #i (i = 1,2,3,4), as indicated in 
Figure 1 9-3 for a group of 4 rows out of the ODTU 12. 

A byte of the ODTU12 JOH is mapped into a JOH byte within the OPU2 OH allocated to OPU2 TS 
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FIGURE 19-3/G.709 
Mapping of ODTU12 (excluding JOH) into OPU2 TribSlot 
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19.3.2 ODTU13 mapping into one OPU3 Tributary Slot 

A byte of the ODTU13 signal is mapped into a byte of an OPU3 TS #i (i - 1,2,..,16), as indicated in 
Figurel9-4 for a group of 4 rows out of the ODTU13. 

A byte of the ODTU13 JOH is mapped into a JOH byte within the OPU3 OH allocated to OPU3 TS 
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FIGURE 19-4/G.709 
Mapping of ODTU13 (excluding JOH) into OPU3 TribSlot 

19.3.3 ODTU23 mapping into four OPU3 Tributary Slots 

A byte of the ODTU23 signal is mapped into a byte of one of four 0PU3 TS #A,B,C,D (A,B,C,D = 
1,2,..,16), as indicated in Figurel9-5 for a group of 4 rows out of the 0DTU13. 

A byte of the ODTU23 JOH is mapped into a JOH byte within the 0PU3 OH allocated to 0PU3 TS 
#a,b,c,d. 



ITU-T G.709 (10/2001)- 



Editor's version 



107 




.^>odu3 ts #a .^--HrT 


ODU3TS#B 













































































ODU3 TS #C ? 











































co 

CO 
CM 



FIGURE 19-5/G.709 

Mapping of ODTU23 (excluding JOH) into 4 OPU3 TribSlots (#A, #B, #C, #D with 

A<B<C<D) 



19.4 OPUk Multiplex Overhead 

The OPUk multiplex overhead consists of Multiplex Structure Identifier (MSI), Justification 
Control (JC) and Negative Justification Opportunity (NJO) overhead. The OPUk MSI, JC and NJO 
overhead locations are shown in Figure 19-6. In addition, two Positive Justification Overhead bytes 
(PJOl, PJ02) are located in the OPUk payload. Note that the PJOl and PJ02 locations are 
multiframe dependent. 
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FIGURE 19-6/G.709 
OPUk Multiplex Overhead 



19.4.1 OPUk Multiplex Structure Identifier (MSI) 

The multiplex structure identifier (MSI) overhead, which encodes the ODU multiplex structure in 
the OPU, is located in the mapping specific area of the PSI signal (PSI[2] PSI[17]). The MSI 
indicates the content of each tributary slot (TS) of an OPU. The generic coding for each TS is 
shown in Figure 19-7. One byte is used for each TS. 

- Bits 1 and 2 indicate the ODU type transported in the TS. 

- Bits 3 to 8 indicate the tributary port of the ODU transported. This is of interest in case of 
flexible assignment of ODUs to tributary slots (e.g. ODU2 into OPU3). In case of fixed 
assignment the tributary port number corresponds to the tributary slot number. 
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1 2 3 4 5 6 7 8 
PSI[1+i] ODU type Tributray Port # TS #/ 



00: ODU1 00 0000: Tributary Port 1 

01 * ODU2 00 0001 : Tributary Port 2 

10- ODU3 00 0010 Tributary Port 3 

11: Res. 00 0011 Tributary Port 4 

00 1111: Tributary Port 16 



FIGURE 19-7/G.709 
Generic MSI coding 



19.4.1.1 OPU2 Multiplex Structure Identifier (MSI) 

For the 4 OPU2 tributary slots 4 bytes of the PSI are used as shown in Figure 19-8. 

- The ODU type is fixed ODU1 . 

- The tributary port # indicates the port number of the ODU1 that is being transported in this TS; 
the assignment of ports to tributary slots is fixed, the port number equals the tributary slot 
number 

The remaining 12 bytes of the MSI field (PSI[6] to PSI[17]) are unused. They are set to 0 and 
ignored by the receiver. 
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FIGURE 19-8/G.709 
OPU2-MSI coding 

19.4.1.2 OPU3 Multiplex Structure Identifier (MSI) 

For the 16 OPU3 tributary slots 16 bytes of the PSI are used as shown in Figure 19-9. 

- The ODU type indicates if the OPU3 TS is carrying ODU1 or. ODU2. 

- The tributary port # indicates the port number of the ODU1/2 that is being transported in this 
TS; for the case of ODU2 a flexible assignment of tributary ports to tributary slots is possible, 
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for the case of ODU1 this assignment is fixed, the port number equals the slot number. ODU2 
tributary ports are numbered 1 to 4. 
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FIGURE 19-9/G.709 
OPU3-MSI coding 



19.4.2 OPUk Payload Structure Identifier Reserved overhead (RES) 

239 bytes are reserved in the OPUk PSI for future international standardisation. These bytes are 
located in PSI[1] and PSI[18] to [PSI255] of the OPUk overhead. These bytes are set to all ZEROs. 

19.4.3 OPUk Multiplex Justification Overhead (JOH) 

The justification overhead (JOH) located in column 16 of the OPUk as indicated in Figure 19-6 
consists of 3 Justification Control (JC) bytes and one Negative Justification Opportunity (NJO) 
byte. The 3 JC bytes are located in rows 1,2 and 3. The NJO byte is located in row 4. 

Bits 7 and 8 of each JC byte are used for justification control. The other six bits are reserved for 
future international standardisation. 
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19.5 Mapping ODUj int ODTUjk 

The mapping of ODUj signals (with up to ±20 ppm bit-rate tolerance) into the ODTUjk signal 
(j=l,2; k=2,3) is performed as an asynchronous mapping. 

NOTE - The maximum bit-rate tolerance between OPUk and the ODUj signal clock, which can 
be accommodated by this mapping scheme, is -1 13 to +83 ppm (ODU1 into OPU2), -96 to +101 
ppm (ODU1 into OPU3) and -95 to +1 01 ppm (ODU2 into OPU3). 

The ODUj signal is extended with Frame Alignment Overhead as specified in 15.6.2.1 and 15.6.2,2 
and an all-0's pattern in the OTUj Overhead field (Figure 19-10); 

The OPUk signal for the multiplexed ODUj structure is created from a locally generated clock 
(within the limits specified in Table 7-3), which is independent of the ODUj 0=1,2)) client signals. 
The extended ODUj signal is adapted to the locally generated ODUk clock by means of an 
asynchronous mapping with -1/0/+1/+2 positive/negative/zero (pnz) justification scheme. 

An ODUj byte is mapped into an ODTUjk byte. 
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FIGURE 19-10/G.709 

Extended ODUj frame structure (FA OH included, OTUj OH area contains Fixed Stuff) 

The asynchronous mapping process generates the JC, NJO, PJOl and PJ02 according to Table 19- 
3. The demapping process interprets JC, NJO, PJOl and PJ02 according to Table 19-3. Majority 
vote (two out of three) shall be used to make the justification decision in the demapping process to 
protect against an error in one of the three JC signals. 



TABLE 19-3/G.709 
JC, NJO, PJOl and PJ02 generation and interpretation 



JC 
17,8] 


NJO 


PJOl 


PJ02 


Interpretation 


00 


justification byte 


data byte 


data byte 


no justification (0) 


01 


data byte 


data byte 


data byte 


negative justification (- 1 ) 


10 


justification byte 


justification byte 


justification byte 


double positive justification (+2) 


11 


justification byte 


justification byte 


data byte 


positive justification (+1) 
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The value contained in NJO, PJOl and PJ02 when they are used as justification bytes is all-Os. The 
receiver is required to ignore the value contained in these bytes whenever they are used as 
justification bytes. 

During a signal fail condition of the incoming ODUj client signal (e.g. OTUj-LOF), this failed 
incoming signal will contain the ODUj-AIS signal as specified in 16.5.1. This ODUj-AIS is then 
mapped into the ODTUjk. 

For the case the ODUj is received from the output of a fabric (ODUj connection function), the 
incoming signal may contain (case of open matrix connection) the ODUj-OCI signal as specified in 
16.5.2. This ODUj-OCI signal is then mapped into the ODTUjk. 

Note - Not all equipment will have a real connection function (i.e. switch fabric) implemented; 
instead the presence/absence of tributary interface port units represents the presence/absence of a 
matrix connection. If such unit is intentionally absent (i.e. not installed), the associated ODTUjk 
signals should carry an ODUj-OCI signal. If such unit is installed but temporarily removed as part 
of a repair action, the associated ODTUjk signal should carry an ODUj-AIS signal. 

The OPUk and therefore the ODTUjk (k=2,3) signals are created from a locally generated clock 
(within the limits specified in Table 17-3), which is independent of the ODUj 0=1,2)) client signal. 

The ODUj 0=1,2)) signal is mapped into the ODTUjk (k=2,3) using a -1/0/+1/+2 
positive/negative/zero (pnz) justification scheme. 

The demapping of ODUj signals from the ODTUjk signal (j=l,2; k=2,3) is performed by extracting 
the extended ODUj signal from the OPUk under control of its justification overhead (JC, NJO, 
PJ01,PJ02). 

NOTE - For the case the ODUj signal is output as an OTUj signal, frame alignment of the 
extracted extended ODUj signal is to be recovered to allow frame synchronous mapping of the 
ODUj into the OTUj signal. 

During signal fail condition of the incoming ODUk/OPUk signal (e.g. in the case of an ODUk-AIS, 
ODUk-LCK, ODUk-OCI condition) the ODUj-AIS pattern as specified in 16.5.1 is generated as a 
replacement signal for the lost ODUj signal. 

19,5.1 Mapping ODU1 into ODTU12 

A byte of the ODU1 signal is mapped into an information byte of the ODTU12 (figure 19-11). Once 
per 4 OPU2 frames, it is possible to perform either a positive or a negative justification action. 

The frame in which justification can be performed is related to the JOH of the OPU2 TS in which 
the ODTU12 is mapped (Figure 19-1). Figure 19-11 shows the case with mapping in OPU2 TS1. 



ITU-T G.709 (10/2001)- 



Editor's version 



113 



MFAS 
bits 
78k 




X 



X 



x 



X 



x 




X 



CM 

to 

CD 



FIGURE 19-11/G.709 
ODTU12 frame format and mapping of ODU1 (case of mapping in TS1) 



19.5.2 Mapping ODU1 into ODTU13 

A byte of the ODU1 signal is mapped into an information byte of the ODTU13 (Figure 19- 12). 
Column 1 19 of the ODTU13 is fixed stuff. An all-Os pattern is inserted in the fixed stuff bytes. 
Once per 1 6 OPU3 frames, it is possible to perform either a positive or a negative justification 
action. 

The frame in which justification can be performed is related to the JOH of the OPU3 TS in which 
the ODTU13 is mapped (Figurel9-2). Figure 19-12 shows the case with mapping in OPU3 TS3. 
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FIGURE 19-12/G.709 
ODTU13 frame format and mapping of ODU1 (case of mapping in TS3) 



19.5.3 Mapping ODU2 into ODTU23 

A byte of the ODU2 signal is mapped into an information byte of the ODTU23 (Figure 19- 13). Four 
times per sixteen OPU3 frames, it is possible to perform either a positive or a negative justification 
action. 

The four frames in which justification can be performed are related to the JOH of the OPU3 TSs in 
which the ODTU23 is mapped (Figure 19-2). Figure 19-13 shows the case with mapping in OPU3 
TS1,TS5, TS9 and TS10. 
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FIGURE 19-13/G.709 
ODTU23 frame format and mapping of ODU2 (case of mapping in TS1,S,9,10) 
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Forward error correction using 16 byte interleaved RS(255,239) codecs 

The forward error correction for the OTU-k uses 16 byte interleaved codecs using a Reed-Solomon 
RS(255,239) code. The RS(255,239) code is a non-binary code (the FEC algorithm operates on byte 
symbols) and belongs to the family of systematic linear cyclic block codes. 

For the FEC processing a OTU row is separated into 16 sub-rows using byte-interleaving as shown 
in Figure A.l. Each FEC encoder/decoder processes one of these sub-rows. The FEC parity check 
bytes are calculated over the information bytes 1 to 239 of each sub row and transmitted in bytes 
240 to 255 of the same sub-row. 

The bytes in an OTU row belonging to FEC sub-row X are defined by: X+16(i-l) (for i=1...255). 



Information bytes Parity check bytes FEC sub-row #16 




OTU 



4 5 6 0 0 



T1 542860-00 
(114739) 

FIGURE A.1/G.709 
FEC sub-rows 

The generator polynomial of the code is given by: 

where a is a root of the binary primitive polynomial x 8 +x 4 +X 3 -fx 2 + L 

The FEC code word (Figure A.2) consists of information bytes and parity bytes (FEC redundancy) 
and is represented by the polynomial 

C(z)=I(z)+R(z) 
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Information bytes are represented by 

I(z) = D254 -J 54 + D253 -J 53 + + D I6 -z 16 
Where Dj (/=16 to 254) is the information byte represented by an element out of GF(256) and 

Dj = d 7j • a 7 + d 6J ■ a 6 + ... + dij -a 1 +doj 
Bit d 7j is the MSB and d 0 j the LSB of the information byte. 
D254 corresponds to the byte 1 in the FEC sub-row and Djs to byte 239. 
Parity bytes are represented by 

R(z) = Ris -z 15 + R14 -z 14 + ... + Rj -z 1 + Ro 
Where R, (/=0 to 15) is the parity byte represented by an element out of GF(256) and 

R/ = r 7J • a 7 + r 6 j - 0? + ... + rij • a 1 + r 0j 
Bit r 7j is the MSB and r 0j the LSB of the parity byte. 
Ri 5 corresponds to the byte 240 in the FEC sub-row and Ro to byte 255. 
R(z) is calculated by 

R(z) = I(z) mod G(z) 

where "mod" is the modulo calculation over the code generator polynomial G(z) with elements out 
of the GF(256). Each element in GF(256) is defined by the binary primitive polynomial 
x 8 +x 4 +X 3 +X 2 +1. 
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transmission order within FEC code word 



238 
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254 


255 


D 17 


D 16 


R15 


Rl4 








Ri 


Ro 



2 3 4 5 6 7 



2 3 4 5 6 7 



r 7j 



Hi 



FIGURE A.2/G.709 
FEC code word 

The Hamming Distance of the RS(255,239) code is dmin=17. The code can correct up to 8 symbol 
errors in the FEC code word when it is used for error correction. The FEC can detect up to 
16 symbol errors in the FEC code word when it is used for error detection capability only. 
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APPENDIX I 



Range of stuff ratios for asynchronous mappings of CBR2G5, CBR10G, and 
CBR40G clients with ±20 ppm bit-rate tolerance into OPUk 

(This Appendix does not form an integral part of this Recommendation) 

Subclause 17.1 describes asynchronous and bit synchronous mappings of CBR2G5, CBR10G, and 
CBR40G clients with ±20 ppm bit-rate tolerance into OPU1, 2, and 3, respectively. For 
asynchronous mappings, any frequency difference between the client and local OPUk clock is 
accommodated by the positive/negative/zero (pnz) justification scheme. The OPUk payload, ODUk, 
and OTUk bit rates and tolerances are given in 7.2. The ODU1, ODU2, and ODU3 rates are 
239/238, 239/237, and 239/236 times 2 488 320 kbit/s, 9 953 280 kbit/s, and 39 813 120 kbit/s, 
respectively. The ODUk bit-rate tolerances are ±20 ppm. This appendix shows that the pnz 
justification scheme can accommodate these bit rates and tolerances, and also derives the range of 
justification (stuff) ratio for each mapping. 

The pnz mapping in 17.1 provides for one positive justification opportunity (PJO) and one negative 
justification opportunity (NJO) in each ODUk frame. Traditionally, the justification ratio (stuff 
ratio) for purely positive justification schemes is defined as the long-run average fraction of 
justification opportunities for which a justification is done (i.e. for a very large number of frames, 
the ratio of the number of justifications to the total number of justification opportunities). In the pnz 
scheme, positive and negative justifications must be distinguished. This is done by using different 
algebraic signs for positive and negative justifications. With this convention, the justification ratio 
can vary at most (for sufficiently large frequency offsets) from -1 to +1 (in contrast to a purely 
positive justification scheme, where justification ratio can vary at most from 0 to 1). Let a represent 
justification ratio (-1 < a < 1), and use the further convention that positive a will correspond to 
negative justification and negative a to positive justification (the reason for this convention is 
explained below). 

Define the following notation: 

N = number of fixed stuff bytes in the OPUk payload area 

S = nominal client rate (bytes/s) 

T = nominal ODUk frame period (s) 

P = ratio of actual frequency difference between the ODUk frequency and client 
frequency and the nominal value of this difference (the nominal value is the 
frequency difference between the ODUk and client frequencies when both are 
nominal). 

N f = average number of client bytes mapped into an ODUk frame, for the particular 
frequency offsets (averaged over a large number of frames) 

Then N/ is given by: 

N f =SpT. (1) 

However, the average number of client bytes mapped into an ODUk frame is also equal to the total 
number of bytes in the payload area (which is (4)(3808) = 15232), minus the number of fixed stuff 
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bytes (iV), plus the average number of bytes stuffed over a very large number of frames. The latter is 
equal to the justification ratio a. Combining this with equation (1) produces: 

Sf5T = 15232- N+a. (2) 



In equation (2), a positive a corresponds to more client bytes mapped into the ODUk, on average. 
However, this would correspond to negative justification. This sign convention is used so that a 
enters in equation (2) with a positive sign (for convenience). 

With the above, the range of a for each client mapping may be determined. It will be seen that in 
the three cases a is in the range [-1, 1]. 



Asynchronous Mapping of CBR2G5 (2 488 320 kbit/s) signal into OPU1 

The nominal ODU1 rate is (239/238)5. But the nominal ODU1 rate is also equal to (4)(3824>T. 
Then 

ST = (4)(3824)— = 15232. (3) 
v 239 

Inserting this into equation (2), and using the fact that N=0 (no fixed stuff bytes) for this mapping 
produces 

a = 15232(/3 -1). (4) 



Since the ODUk and client frequency tolerances are each ±20 ppm, P ranges from 0.99996 to 
1.00004. Using this in equation (4) gives as the range of a 

- 0.60928 < a < -K).60928 . (5) 



Asynchronous Mapping of CBR10G (9 953 280 kbit/s) signal into OPU2 

The nominal ODU2 rate is (239/237)5. But the nominal ODU2 rate is also equal to (4)(3824)/r. 
Then 

ST= (4)(3824)— = 15168 . (6) 
239 

Inserting this into equation (2), and using the fact that N=64 (number of fixed stuff bytes) for this 
mapping produces 

a = 15168j3 + 64-15232 = 15168(0-1). (7) 



As before, the ODUk and client frequency tolerances are ±20 ppm, and P ranges from 0.99996 to 
1 .00004. Using this in equation (7) gives as the range of a 

- 0.60672 < a < +0.60672. (8) 
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Asynchronous Mapping of CBR40G (39 813 120 kbit/s) signal into OPU3 

The nominal ODU3 rate is (239/236)5. But the nominal ODU3 rate is also equal to (4)(3824)/7'. 
Then 

S7/ = (4)(3824)— = 15104. (9) 
239 

Inserting this into equation (2), and using the fact that N=128 (number of fixed stuff bytes) for this 
mapping produces 

a = 15104)5 + 128-15232 = 15104(0 -1) . (10) 

As before, the ODUk and client frequency tolerances are ±20 ppm, and fi ranges from 0.99996 to 
1.00004. Using this in equation (7) gives as the range of a 

-0.60416<a<+0.60416. (11) 
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APPENDIX II 



Examples of functionally standardised OTU frame structures 



This appendix provides examples of functionally standardised OTU frame structures. These 
examples are for illustrative purposes and by no means imply a definition of such structures. The 
completely standardised OTUk frame structure as defined in this Recommendation is shown in 
Figure II. 1. Functionally standardised OTUkV frame structures will be needed to support, e.g. 
alternative FEC. Examples of OTUkV frame structures are: 

OTUkV with the same overhead byte allocation as the OTUk, but use of an alternative FEC 

as shown in Figure IL2; 

OTUkV with the same overhead byte allocation as the OTUk, but use of a smaller, 
alternative FEC code and the remainder of the OTUkV FEC overhead area filled with fixed 
stuff as shown in Figure II.3; 

OTUkV with a larger FEC overhead byte allocation as the OTUk, and use of an alternative 
FEC as shown in Figure II.4; 

OTUkV with no overhead byte allocation for FEC as shown in Figure IL5; 
OTUkV with a different frame structure than the OTUk frame structure, supporting a 
different OTU overhead (OTUkV overhead and OTUkV FEC) as shown in Figure EE.6; 
OTUkV with a different frame structure than the OTUk frame structure, supporting a 
different OTU overhead (OTUkV overhead) and with no overhead byte allocation for FEC 
as shown in Figure IL7. 



\ Column 
Row 



FA OH OTUk OH 


R^1jRS<255,239) FEC adundanq 


OTUk Payload =ODUk 


Row 2 RS<2Jp39) FEC redundancy 
RowaR^S^FECredundand 
Row 4 RS(255 t 239) FEC redundancy 



FIGURE II.1/G.709 
OTUk (with RS(255,239) FEC) 
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FIGURE II.2/G.709 
OTUkV with alternative FEC 
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^ ; : 


Fixed Stuff 
(ALL-0's) 



FIGURE II.3/G.709 

OTUkV with a smaller FEC and remainder of FEC area filled with fixed stuff 




FIGURE II.4/G.709 
OTUkV with a larger FEC 
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FIGURE II.5/G.709 
OTUkV without FEC area 
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FIGURE II.6/G.709 
OTUkV with different frame structure 



\ Column 
Row\ 1 

1 



Xi X^1 



Xi+X 2 



OTUkV Overhead 
(YxX, bytes) 



OTUkV Payload =ODUk 



FIGURE II.7/G.709 
OTUkV with different frame structure and without FEC area 
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The mapping of the ODUk signal into the OTUkV may be either frame synchronous, asynchronous, 
or bit synchronous for the case of Figure II. 1 to Figure IL5. For the case of Figure II.6 and 
Figure II.7, the mapping of the ODUk signal can be either asynchronous or bit synchronous. 

For the case of an asynchronous mapping, the ODUk and OTUkV bit rates can be asynchronous. 
The ODUk signal is mapped as a bit stream into the OTUkV payload area using a stuffing 
technique. 

For the case of a bit synchronous mapping, the ODUk and OTUkV bit rates are synchronous. The 
ODUk signal is mapped into the OTUkV payload area without stuffing. The ODUk frame is not 
related to the OTUkV frame. 

For the case of a frame synchronous mapping, the ODUk and OTUkV bit rates are synchronous and 
the frame structures are aligned. The ODUk signal is mapped into the OTUkV payload area without 
stuffing and with a fixed position of the ODUk frame within the OTUkV frame. 
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FIGURE II.8/G.709 
Asynchronous (or bit synchronous) mapping of ODUk into OTUkV 
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APPENDIX III 



Example of ODUk multiplexing 

Figure ELI illustrates the multiplexing of four ODU1 signals into an ODU2. The ODU1 signals 
including the Frame Alignment Overhead and an all-O's pattern in the OTUk Overhead locations are 
adapted to the ODU2 clock via justification (asynchronous mapping). These adapted ODU1 signals 
are byte interleaved into the OPU2 Payload area, and their justification control and opportunity 
signals (JC, NJO) are frame interleaved into the OPU2 Overhead area. 

ODU2 Overhead is added after which the ODU2 is mapped into the OTU2 [or OTU2V]. OTU2 [or 
OTU2V] Overhead and Frame Alignment Overhead are added to complete the signal for transport 
via an OTM signal. 




FIGURE III. 1/G.709 
Example of multiplexing 4 ODU1 signals into an ODU2 (artist impression) 
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APPENDIX IV 



Example of Fixed Stuff in OPUk with multiplex of lower order ODUk signals 

When an OPU3 transports 16 ODU1 signals, columns 1905 to 1920 of the OPU3 contain fixed 
stuff; one fixed stuff column for each of the 16 ODU1 signals. 




FIGURE IV. 1/G.709 
Fixed Stuff locations when mapping 16x ODU1 into OPU3 
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APPENDIX V 



Range of stuff ratios for asynchronous multiplexing of ODUj into ODUk (k > j) 

Appendix I derives a relation between client rate, server frame time, amount of fixed stuff, and stuff ratio, for 
the asynchronous mapping of CBR (STM-N) clients into ODUk. In this Appendix the result of Appendix I 
(Eq. (2) in Appendix I) is generalised to apply also to the asynchronous multiplexing of ODUj into ODUk (k 
> j). The more general result is used to evaluate the range of stuff ratio for the multiplexing of ODU1 into 
ODU2, ODU1 into ODU3, and ODU2 into ODU3, assuming all ODU clocks have ± 20 ppm frequency 
tolerance. 

The asynchronous mapping of an STM-N client into ODUk is asynchronous, and uses a +1/0/-1 byte stuffing 
scheme. The asynchronous mapping of an ODUj client into ODUk (k > j) is asynchronous, and uses a 
+2/+1/0/-1 byte stuffing scheme. For the case of multiplexing, the ODUj being mapped will get only a 
fraction of the full payload capacity of the ODUk. There can be, in general, a number of fixed stuff bytes per 
ODUj or STM-N client. The magnitude of the justification ratio, a, is the long-run average fraction of stuff 
opportunities for the client in question where a stuff is actually done. The justification ratio takes on both 
positive and negative values. For consistency, the sign convention of Appendix I is followed, where positive 
a corresponds to negative stuffing and negative a corresponds to positive stuffing. It is explained in 
Appendix I that this convention is used so that a appears with a positive sign in the main result (Eq. (2) of 
Appendix I and Eq. (3) here). Note that there is one stuff opportunity every ODUk frame. For mapping of 
STM-N into ODUk, the STM-N client is allowed to use all the stuff opportunities (because only one STM-N 
signal is mapped into an ODUk). However, for mapping ODUj into ODUk (k > j), the ODUj can only use 
1/4 or 1/16 of the stuff opportunities (the former for mapping ODU1 into ODU2 or ODU2 into ODU3; the 
latter for mapping ODU1 into ODU3). The other stuff opportunities are needed for the other clients being 
multiplexed into the ODUk. The stuff ratio a is defined relative to the stuff opportunities available for the 
client in question; the range of a is therefore -1 to +2 in all cases of ODU multiplexing. 

Following Appendix I, define the following notation (the index j is used to refer to the possible ODUj client 
being mapped, and the index k is used to refer to the ODUk server layer into which the ODUj or STM-N 
client is mapped): 



N = 


number of fixed stuff bytes in the OPUk payload area associated with the client in question 




(note that this is not the total number of fixed stuff bytes if multiple clients are being 




multiplexed) 


S = 


nominal STM-N or ODUj client rate (bytes/s) 


T = 


nominal ODUk frame period (s) 


y c = 


client frequency offset (fraction) 


y* = 


server frequency offset (fraction) 


p = 


fraction of OPUk payload area available to this client 


N, = 


average number of client bytes mapped into an ODUk frame, for the particular frequency 




offsets (averaged over a large number of frames) 



Then N f is given by: 
1+ v 

N =ST -Js.. (1) 
l+y, 

For frequency offsets small compared to 1, this may be approximated 

N,=ST(l + y c -y s ) = STp. (2) 
The quantity ^-1 is the net frequency offset due to client and server frequency offset. 
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Now, the average number of client bytes mapped into an ODUk frame is also equal to the total number of 
bytes in the payload area available to this client (which is (4)(3808)/? = 15232p), minus the number of fixed 
stuff bytes for this client (AO, plus the average number of bytes stuffed for this client over a very large 
number of frames. The latter is equal to the justification ratio a multiplied by the fraction of frames p 
corresponding to justification opportunities for this client. Combining this with equation (1) produces: 

ST/3 -ap + \ 5232/? - N . (3) 

In equation (3), a positive a corresponds to more client bytes mapped into the ODUk, on average. As 
indicated above, this corresponds to negative justification. This sign convention is used so that a enters in 
equation (2) with a positive sign (for convenience). 

Eq. (3) is the main result, and is a generalisation of Eq. (2) in Appendix I. For mapping STM-N into ODUk, 
the quantity p is 1, and Eq. (3) reduces to Eq. (2) in Appendix I. 

The range of stuff ratio may now be determined for mapping ODUj into ODUk, using Eq. (3). In what 
follows, \&R I6 be the STM-16 rate, i.e., 2.48832 Gbit/s. 

ODU1 into ODU2 Multiplexing 

The ODU1 nominal client rate is (see 7.3) 

S = — * 16 . (4) 
238 16 

The ODU2 nominal frame time is 

T= (3824)(4) . (5) 
239 

237 ^ 16 ' 

The fraction p is 0.25. Inserting into Eq. (3) produces 

239 Mli 0=2+3808-*. (6) 

»» "»(«,.) 4 
237 167 

Simplifying and solving for a produces 

a = — (15296) P + 4N- 15232. (7) 
238 

Now let P = 1+ y, where y is the net frequency offset (and is very nearly equal to y c - y s for client and server 
frequency offset small compared to 1). Then 

a = — (1 5296) - 1 5232 + 4N + — (1 5296)>> 

238 238 • (8) 

= 4N- 0.2689076 + 1523 1 .73 1092j 



The number of fixed stuff bytes N is zero, as given in subclause 19.5.1 of G.709. The client and mapper 
frequency offsets are in the range ± 20 ppm, as given in 7.3. Then, the net frequency offset y is in the range ± 
40 ppm. Inserting these values into Eq. (8) gives for the range for a 
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a = 0.340362 for 7 = +40 ppm 

a = -0.268908 for ^ = 0ppm . (9) 
a = -0.878177 for y = -40ppm 

In addition, stuff ratios of -1 and +2 are obtained for frequency offsets of -47.998 ppm and 148.96 ppm, 
respectively. The range of frequency offset that can be accommodated is approximately 197 ppm. This is 
50% larger than the range that can be accommodated by a +1/0/-1 justification scheme (see Appendix I), and 
is due to the additional positive stuff byte. 

ODU2 into ODU3 Multiplexine 

The ODU2 nominal client rate is (see 7.3) 

S~(4R U ). (12) 
The ODU3 nominal frame time is 

r= J3824X4)_ (B) 
The fraction p is 0.25. Inserting into Eq. (3) produces 

m^Jspssa-^z^-H. (14) 
237 |go«w 4 

Simplifying and solving for a produces 

a = -^y (15296)0 + 4N- 15232 . (15) 

As before, let p = 1 + y, where y is the net frequency offset (and is very nearly equal to y c - y s for client and 
server frequency offset small compared to 1). Then 

a = — (1 5296) - 1 5232 + AN + — (1 5296)>> 

237 237 . (16) 

= 4N- 0.5400844 + 1 523 1 .4599 1 6y 

The number of fixed stuff bytes N is zero, as given in 19.5.3. The client and mapper frequency offsets are in 
the range ± 20 ppm, as given in 7.3. Then, the net frequency offset y is in the range ± 40 ppm. Inserting these 
values into Eq. (16) gives for the range for a 



a = 


0.0691740 


for 


y 


= +40 ppm 


a = 


-0.5400844 


for 


y 


= Oppm 


a = 


-1.149343 


for 


y 


= -40 ppm 



(17) 



In addition, stuff ratios of -1 and +2 are obtained for frequency offsets of -30.195 ppm and 166.77 ppm, 
respectively. As above, the range of frequency offset that can be accommodated is approximately 197 ppm, 
which is 50% larger than the range that can be accommodated by a +1/0/-1 justification scheme (see 
Appendix I) due to the additional positive stuff byte. 
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ODU1 into ODU3 Multiplexing 

The ODU1 nominal client rate is (see 7.3) 




(20) 



The ODU3 nominal frame time is 




(21) 




(22) 



Simplifying and solving for a produces 



236 
238 



(15296)/3 + 16N- 15232. 



(23) 



As before, let P = 1 + y, where y is the net frequency offset (and is very nearly equal to y c - y, for client and 
server frequency offset small compared to 1). Then 

a = —(15296) - 15232 + \6N + — (15296)>> 

238 238 . (24) 

= 1 6N - 64.5378 1 5 1 + 1 5 1 67.462 1 &5y 

The total number of fixed stuff bytes in the ODU3 payload is 64, as given in 19.5.2; the number for one 
ODU1 client, N, is therefore 4. The client and mapper frequency offsets are in the range ± 20 ppm, as given 
in 7.3. Then, the net frequency offset y is in the range ± 40 ppm. Inserting these values into Eq. (24) gives 
for the range for a 



a 


= 0.0688834 


for 


y 


= +40 ppm 


a 


= -0.5378151 


for 


y 


= 0ppm 


a 


= -1.144514 


for 


y 


= -40 ppm 



In addition, stuff ratios of -1 and +2 are obtained for frequency offsets of -30.472 ppm and 167.32 ppm, 
respectively. As above, the range of frequency offset that can be accommodated is approximately 197 ppm, 
which is 50% larger than the range that can be accommodated by a +1/0/- 1 justification scheme (see 
Appendix I) due to the additional positive stuff byte. 
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